andr_gin schrieb:
Ich denke da wird Samsung einfach die Brieftasche gezückt haben, um dafür zu sorgen, dass die ganze Sache im Sand verläuft und nicht mehr berichtet wird.
Denken kann man vieles, aber Sinn macht es nicht.
andr_gin schrieb:
Ähnlich ist es ja bei der 840er Evo bzw. Basic gelaufen, so Samsung mit ein paar Firmwareupdates versucht hat das grundsätzliche Problem des TLC Speichers zu verschleiern, dass dieser innerhalb weniger Wochen/Monate seine Daten verliert
Auch das ist totaler Schwachsinn, es hat nicht eine 840 oder 840 Evo bei einem User hier oder in anderen Foren die ich lesen, die Daten verloren, jedenfalls nicht das ist davon gelesen hätten. Das Problem ist immer nur, dass die nach einiger Zeit langsamer gelesen werden. Setzen bitte keine unrichtigen Behauptungen in die Welt die andere nur verunsichern.
andr_gin schrieb:
Legt man hier z.B. ein Notebook ein Jahr ins Regal, wird man damit rechnen müssen, dass alles weg ist.
Lange unbenutzt rumliegen ist etwas ganz anderes und geht in den Bereich der Langzeitdatenspeicherung, das ist ein ganz anderes Thema. Die JEDEC sieht als Brachenverband der Industrie in der JESD218 für Consumer SSDs eine offline Data Retention Time von 12 Monaten bei 30°C vor, diese ist bis zum Erreichen der spezifizierten P/E Zyklen einzuhalten, bzw. sind die P/E Zyklen so zu spezifizieren, dass diese eingehalten wird.
Das schlechte NAND Qualitäten auch eine schlechtere Data Retention Time haben können, ja sogar wahrscheinlich haben werden und das einige SSD Hersteller solche NANDs verbauen und sich dann eben vermutlich auch nicht an die Standards ihren Herstellerverbandes JEDEC halten, sollte auch klar sein. Man sieht es auch bei den RAMs,
JEDEC spezifiziert DDR3 RAM nur bis 1.5V und bis PC3-14900 (1866), mehr ist bei 1.5V auch kaum zu machen. Aber
schau man sich an wer die DDR3 RAM Riegel mit darüberlegenden Spannungen und Frequenzen anbietet, das sind es meist Hersteller die auch SSDs anbieten und keiner von denen stellt auch nur einen Wafer mit NAND Flash oder DRAM selbst her! Die haben alle gar keine Fabs. Die wirklichen DRAM Fertiger mit den Fabs, es sind ja nur Micron (mit Tochter Crucial), Nanya (mit Tochter Elixir), SK Hynix und Samsung,
die bieten solche RAM Riegel die nicht der JEDEC entsprechen, gar nicht an.
Cool Master schrieb:
Bietet Crucial auch Server SSDs an?
Nein, Micron verkauft für Enterprise- und OEM Kunden unter eigenen Label und nicht über die Töchter, also Crucial für RAM und SSDs, Lexar für USB Sticks und Speicherkarten.
Marco^^ schrieb:
Da sind soo viele Variablen, rate mal mit Rosenthal ...
So ist es und der Queued TRIM Bug bei Crucial ist bei der m500 normalen Usern aufgefallen, es wäre also anzunehmen, dass auch andere Nutzer von Samsung SSDs Probleme hätten, wenn es ein Problem der FW ist und da ja angeblich auch die Enterprise SSDs von Samsung betroffen sind, im Enterprise Segment ist Samsung die Nummer 2 hinter Intel, werden nicht wenige von denen auch unter Linux laufen.
Marco^^ schrieb:
NEIN, Crucial ist eine Tochterfirma von Micron, aber die SSDs die unter dem Label Crucial verkauft werden, sind nicht 100%ig identisch mit denen die unter dem Label von Micron verkauft werden. Da reichen schon Änderungen in der FW um Unterschiede auszumachen. Dazu gibt es von Micron selbst auch Modelle für die es unter dem Label Crucial keine vergleichbaren Gegenstücke gibt die sich nur in der FW und dem Label unterscheiden, wie die P320h oder die M500 DC.
Jesterfox schrieb:
Wenn es ein Problem mit Queued Trim ist betrifft es auch Crucial
Es betrifft Crucial und bei der m500 wurde es nie behoben, steht doch auch so im Text!
orioon schrieb:
Linux ist Auslöser, da würfelst da einiges durcheinander...
Was noch nicht klar ist und wenn sonst niemand damit Probleme hat, spricht es auch dagegen, immerhin wurden bei der m500 der Bug ja auch von mehreren Leuten gefunden und bestätigt.
orioon schrieb:
Die SSD Firmware ist Schuld, sofern man keinen Fehler in der Linux Implementierung nachweisen kann.
Auch das muss nicht sein, es steht immerhin im Text:
Samsung habe Algolia mehrfach um Zugriff auf deren Software gebeten, um für gleiche Bedingungen zu sorgen, doch aus Datenschutzgründen verweigerte die Firma dies.
Ab dieser Woche soll es weitere Versuche seitens Samsung geben, den Fehler zu reproduzieren. Ein neues Script soll dabei helfen. Mit dem ersten Script von Algolia waren angeblich keine Fehler aufgetreten.
Demnach hat man nicht mit der realen SW testen können, sondern deren Verhalten mit einem Script simuliert und das Script erzeugt die Probleme nicht. Wie kann man also ausschließen, dass ein Fehler in der SW vorliegt? Ohne die zu kennen, ist das doch unmöglich und Algolia rückt die nicht raus. Wenn außer Algolia niemand das Problem hat und Samsung es auch nicht nachgestellt bekommt, ist für mich die SW von Algolia der Hauptverdächtige.
orioon schrieb:
Und davon ist derzeit auszugehen, es könnten aber auch durchaus Fehler in beiden Komponenten den Fehler verursachen.
So ist es, ein Hund hat oft mehr als einen Floh im Pelz und hier kommen schon 3 Kandidaten zusammen: SSD, OS und Programm.
Mäuschen schrieb:
Wie Bitte?! Da fehlt eine Quellenangabe.
Da wirst Du wohl auch lange drauf warten oder einen Unsinn bekommen, der mit dem Thema nichts zu tun hat, etwas den Links zu dem Bericht, dass bei entsprechenden Schreib- und Lagertemperaturen die DRT auch auf wenige Wochen fallen kann. Das geht aber am Thema vorbei.
Mäuschen schrieb:
Ich habe davon gehört, dass die Daten langsamer gelesen werden, mehr nicht.
Genauso ist es auch, lass Dich nicht verarschen!
Mäuschen schrieb:
Aber du klingst ja sehr überzeugt.
Das finde ich nun wirklich nicht! Natürlich ist eine SSD kein Langzeitarchivmedium, aber CDs, DVDs, Tapes oder HDDs die man nach einige bis vielen Jahren aus dem Schrank holt, gehen oft auch nicht mehr. Außerdem sind SSDs pro GB zu teuer um die einfach im Schrank oder Keller als Langzeitarchiv lagern zu lassen und wichtige Daten lagert man niemals nur auf einem Datenträger!
Mäuschen schrieb:
Wenn das so wäre würden wohl kaum mehr SSDs mit TLC verkauft und selbst Samsung hätte es nicht geschafft das Problem so herunter zu spielen.
So ist es und nach Samsung und Toshibas Ultra II kommt mit der OCZ Trion, die von OCZ nur vertrieben wird aber von Toshiba entwickelt wurde und gefertigt wird, nun schon wieder eine TLC auf den Markt und noch mit planarem TLC NAND im 19nm Prozess. Toshiba plant sogar von seinem 15nm NAND eine TLC Version. Wie Du siehst merkt selbst Du nach kurzen Nachdenken, das andr_gin gar nicht überzeugend rüberkommt, sondern nur Unsinn und Verunsicherung verbreitet damit er Samsung bashen kann.
White_Eagle schrieb:
Habe mal eine Frage zu TRIM, "der Bereinigung von Datenblöcken".
TRIM ist keine "Bereinigung von Datenblöcken", es ist eine Mitteilung an den Controller der SSD, das die Daten die bestimmten LBAs zugeordnet sind, nun nicht mehr benötigt werden. Die SSD kann diese löschen muss es aber nicht sofort tun und praktisch hebt der Controller einfach nur die Verknüpfung zwischen dem LBA und den Daten auf und markiert diese als ungültig. Bei der nächsten Garbage Collection, egal ob während eines Schreibvorgangs oder bei der Idle-GC, brauchen diese dann nicht mehr kopiert zu werden und werden mit dem Block gelöscht, wenn der zum Löschen ausgewählt wurde. Die Chance dafür erhöhen sich natürlich auch, je mehr Pages in dem Block ungültige Daten enthalten.
Ungültig sind für den SSD Controller alle Daten deren LBAs getrimmt oder überschrieben wurden, beim Überschrieben kann er ja die alten Daten nicht wie eine HDD überschrieben, der muss diese ja in anderen Pages schreiben und das Mapping der LBAs dann auf diese neuen Adressen anpassen. Er wird auch nicht jeden Block sofort löschen wenn da ein paar LBAs getrimmt wurden, denn NAND kann man nur blockweise löschen, aber pageweise lesen und schreiben. Eine Page hat heute 8k oder 16k, ein Block hat 512 oder 1024 Pages, würde nur eine Page in dem Block getrimmt und die anderen z.B. 1023 haben noch gültige Daten, müssten diese ganze Daten erst einmal intern kopiert werden, was eine gewaltige Write Amplification bewirken würde, also einen sehr hohen Verschleiß den TRIM ja gerade vermindern soll.
White_Eagle schrieb:
Ich habe 3 SSD, mit NAND-Typ: MLC:
- 1x Transcend SSD370 (TS512GSSD370) 512GB,
- 1x Crucial MX100 (CT512MX100SSD1) 512GB (mit Firmenwareupdate) und
- 1x Crucial MX200 (CT500MX200SSD1) 500GB,
bei allen 3 SSD ist kein TRIM vorhanden und läßt sich ein solcher auch nicht aktivieren?
Alle 3 unterstützen TRIM, wenn TRIM nicht funktioniert, liegt es an etwas anderem, dem OS oder dem Treiber. Welche OS verwendest Du? Wenn es Windows ab Win 7 ist, welchen Treiber? Poste dafür den Screenshot von
Drive Controller Info!
Wie kommst Du darauf das kein TRIM vorhanden ist? Teste es mal, aber
fsutil behavior query DisableDeleteNotify zeigt nur an, ob Windows überhaupt TRIM Befehle schickt und Tools wie
CrystalDiskInfo zeigen die Eigenschaften der Disks an, also ob der Controller überhaupt TRIM Befehle versteht, was bei Deinen 3 SSDs der Fall ist. Es zeigt aber nicht ob der Controller wirklich TRIM Befehle bekommt, TRIM also wirklich funktioniert. Das kann man nur mit dem Tool
TrimCheck prüfen, man lässt es zweimal laufen, beim ersten mal wird die Testdatei erzeugt und gelöscht, beim zweiten mal wird geschaut ob TRIM funktioniert hat. Dazwischen sollte man nichts am Rechner machen und ein paar Minuten warten. Wurde TRIM nicht als funktionierend erkannt, kann man es auch erneut laufen lassen und es prüft die Daten noch einmal. TrimCheck muss auf der SSD liegen, wenn es ausgeführt wird, der User muss in dem Verzeichnis Schreibrechte haben und es darf weder verschlüsselt noch komprimiert sein.
White_Eagle schrieb:
Hast Du eine Corsair SSD? Nein, also vergiss das Tool!
White_Eagle schrieb:
Einen speziellen "
Trim Enabler 3.4.1" habe ich nur für das OS von MAC gefunden.
Den brauchst Du für Windows auch nicht, das Trimmt alle SSDs, aber eben erst ab Win7, XP und Vista können das nicht und es trimmt keine SSDs an SAS Controllern oder über USB, die müssen als an einem Port eines SATA Host Controllers hängen.
Starte eine cmd.exe mit Administratorrechten und führen folgenden Befehl genau so aus:
fsutil behavior query DisableDeleteNotify
Dann sollte d
DisableDeleteNotify = 0
Wenn nicht, dann führe diesen Befehl aus:
fsutil behavior set DisableDeleteNotify 0
Das ist der Trim Enabler für Windows, sonst von Microsoft ins System eingebaut!
White_Eagle schrieb:
Ich werde da aber nicht schlau daraus, außer daß Curical TRIM als "Active Garbage Collection" bezeichnet, bei Curical es in der Firmenware integriert ist, unabhänngig vom verwendetem OS ausgeführt wird,
Eine Idle-GC haben alle modernen SSD Controller schon lange, das ersetzt aber TRIM nicht!
AMIN
DIA, es gibt so viele andere SSDs und SSD Hersteller über die ich auch kritisch schreiben, zu Crucial, Intel und Samsung haben ich schon Kritik geäußert, da fällt AMD, die ja nicht einmal ein Hersteller sind und die SSDs von OCZ sogar vertreiben lassen, nun wirklich nicht auf. AMD solltest Du das Geld für Dein Guerilla-Marketing wieder zurückerstatten, die können es sich wirklich nicht leisten noch mehr schlechte Leute zu bezahlen
