News OCZ Intrepid 3000 mit Marvell-Controller im Handel

[deodor]

...nie mehr als ein Bit zu schreiben und nicht einfach wie OCZ und Toshiba im ganze NAND Bereich zuerst ein Bit zu schreiben und dann doch noch die weiteren Bits hinterher.

Die Behauptung ist irreführend. Bei MLC und verschärft bei TLC stehen meistens verschiedene Dateien in einem Flash-Block. Wenn eine dieser 2 oder 3 Dateien gelöscht wird und die SSD hinreichend gefüllt ist, dann muss dieser Block wieder benutzt werden und dafür muss er gelöscht und komplett mit alten und neuen Daten neu geschrieben werden. Davon ist die Samsung EVO mit TLC am stärksten betroffen.

 

[Hallo32]

In den OCZ Foren schau ich selten rein, seid die vor einiger Zeit angefangen haben alle kritischen Fälle per PM weiter zu behandeln.

Jeder Fall der hinter verschlossenen Türen behandelt wird, ist für mich ein vollständiger Brick ohne bekannte Ursache.

Wo das Problem liegt, kann ich mir sogar so denken: Die beschreiben ja immer zuerst das erste Bit um die hohen Schreibraten zu erreichen und dann erst das zweite Bit. Kommt es dabei zu einem Problem, wie etwa einem unerwarteten Spannngsunterbrechung, so stimmen die Werte im ersten Bit auch nicht mehr und da die zu einer anderen Datei gehören, ist die dann korrupt. Samsung hat sich schon was dabei gedacht bei der Evo einen festen Bereich für das Pseudo-SLC des Turbo Write Schreibcaches zu nehmen und da auch nie mehr als ein Bit zu schreiben und nicht einfach wie OCZ und Toshiba im ganze NAND Bereich zuerst ein Bit zu schreiben und dann doch noch die weiteren Bits hinterher.

Ob das die wirkliche Ursache ist, ist mir nicht bekannt, weil man dieses relativ einfach umgehen könnte.
1) Die ersten Bits der Page A lesen.
2) Die ersten Bits der Page B lesen.
3) Daten im Controller zusammenfassen.
4) Die "ganzen Bits" in der leeren Page C aus der OP Area schreiben.
5) FTL auf die Page C zeigen lassen, A und B für GC freigegeben.

Ob der BF3 Daten im Cache speichert ohne die Daten im Nand zu haben? Evtl. passiert dieses als Zwischenstufe zwischen Sata Interface und Nand. Aber das sind alles Spekulationen.

 

[Holt]

Es gibt nicht um Flash-Blöcke. Das da mehrere Dateien drin stehen, ist schon wegen deren Größe von meist über 1MB komplett logisch. Es geht um die Bits, die man bei MLC und TLC der Reihe nach programmiert und da geht das Programmieren des ersten Bit eben viel schneller als beim zweiten Bit, weshalb OCZ seid der Vertex4 immer erst nur ein Bit beschreiben, womit aber nur die Hälfte der Kapazität zur Verfügung steht, so dass die zweite Hälfte dann in die jeweils zweiten Bits geschrieben werden muss, weshalb auch die Schreibrate nach rund 50% massiv abfällt.

OCZ nennt das den Performance Mode:

The Performance Mode

With the 1.4 firmware OCZ introduced a two operating mode structure for most capacities of the Vertex 4. As long as less than 50% of the drive is in use, the Vertex 4 will operate in a performance mode - delivering better sequential performance. Once you hit the 50% mark, the drive switches to its standard performance mode (similar to the max performance pre-1.4 firmware).

This mode switching is mostly transparent to the end user with one exception. When you cross the 50% threshold, the Vertex 4 has to reorganize all pages on the drive. During this reorganization performance is impacted.

Wobei es natürlich nicht stimmt, dass die ganzen Daten in den Pages reorganisiert werden, wenn die 50% erreicht sind, sonst würde die SSD ja gar eine ganze Weile lang gar nichts mehr schreiben können. Das interne umkopieren macht die FW im Idle, so dass dann nach einiger Zeit wieder die Hälfte der noch freien Kapazität schnell beschrieben werden kann, aber in der Zeit darf halt kein unerwarteter Stromausfall kommen.

Und wovon ist die Evo am stärksten betroffen? Das das Pseudo-SLC mehr P/E Zyklen erlebt als die übrigen NANDs ist klar, aber weil ja auch nur ein Bit dort geschrieben wird, hält das auch viel mehr Zyklen aus, laut Samsung über 30.000! Nicht betroffen ist die Evo aber von der Veränderung der Informationen im ersten Bit wenn das zweite geschrieben wird, denn das passiert ja im Turbo.Write Cache niemals.

 

[Hallo32]

Nach den obigen Verfahren können die Daten ohne Verlust zusammengefasst werden. Ob dieses nun auf Page/Block/Die/File Ebene passiert, spielt nur in der Abstraktion eine Rolle aber nicht in der Praxis für den Enduser.

Die Zeitdauer des Umschreiben der Bits müsste man sich einmal ausrechnen.

 

[Holt]

Jeder Fall der hinter verschlossenen Türen behandelt wird, ist für mich ein vollständiger Brick ohne bekannte Ursache.

Das sind dann die Fälle, wo die Ursache wohl am interessantesten wäre, weil sich da wohl ein Bug gezeigt hat.

Ob das die wirkliche Ursache ist, ist mir nicht bekannt, weil man dieses relativ einfach umgehen könnte.
1) Die ersten Bits der Page A lesen.
2) Die ersten Bits der Page B lesen.
3) Daten im Controller zusammenfassen.
4) Die "ganzen Bits" in der leeren Page C aus der OP Area schreiben.
5) FTL auf die Page C zeigen lassen, A und B für GC freigegeben.

Genau das passiert ja auch, aber nachher im Idle, wenn es nicht auf die Performance geht, Würde man es während des Schreibvorgangs machen, hätte man bessere Schreibraten wenn man auf den ganzen Trick gleich verzichten würde, denn das dauert natürlich auch entsprechend lange. Wenn intensiv geschrieben wird, verzichten die Controller ja auch gleich ganz auf den Trick und schreiben direkt beide Bits zusammen ins NAND, was man bei der Performance Consistancy sieht und bei manchen Reviews auch beim Schreiben:

Mit dem Perfromance Mode sieht es so aus:


Ohne den Performance Mode, etwa weil schon alle LBA beschrieben sind, dann so:


Vergleicht man dann die letzten Kurve nach der Folter mit Random Write bei Hardwareluxx:


mit der bei Anandtech, so sieht man auch, dass seine 2000s Random Write Folter nicht gereicht haben, denn es kommt nicht auf die Zeit an, sondern darauf die ganze SSD dabei zu überschreiben:



Man kann eben bei solche Tests viel falsch machen und damit, ob bewusst oder unbewusst, eine SSD besser aussehen lassen. Das ist ihm aber schon beim Review der Crucual v4 passiert, deren IOPS schreibend so mies sind, dass es kaum einen Unterschied macht ob er sie 20min oder 60min foltert, er bekommt dabei immer noch nur einen Bruchteil der Kapazität überschrieben.

Ob der BF3 Daten im Cache speichert ohne die Daten im Nand zu haben? Evtl. passiert dieses als Zwischenstufe zwischen Sata Interface und Nand. Aber das sind alles Spekulationen.

Das machen alle Controller, schalte mal den Schreibcache ab und schau Dir die 4k Schreibrate an, wenn die SSD ein sync.faking betreibt fallen die auf wenige MB/s zusammen. Aber das passiert in extrem engen Grenzen, zumindest bei SSD die keine Stützkondensatoren haben und wenn sie welche haben, darf die SSD auch sync-faking machen, sie kann die Daten ja noch aus eigener Kraft zurückschreiben. Das ist das gleiche wie bei RAID Controller mit oder ohne BBU.

 

[deodor]

Es gibt nicht um Flash-Blöcke.

Du bist verwirrt oder willst verwirren.

im ganze NAND Bereich zuerst ein Bit zu schreiben und dann doch noch die weiteren Bits hinterher.

Bei TLC muss entsprechend öfter reorganisiert werden. Wann das geschieht, stand nicht zur Diskussion. Das ist egal. Das erhöhte Risiko bleibt gleich.

 

[Holt]

Nach den obigen Verfahren können die Daten ohne Verlust zusammengefasst werden.

Das geht aber nur, solange wirklich nur ein Bit geschrieben wurde, eben wie es die Evo im TurboWrite Cache macht. Das Problem bei der Vorgehensweise von OCZ und Toshiba ist:

Lower page corruption: MLC or E‐MLC NAND flash uses each physical page to store the data of two logical pages; each memory cell represents two bits. The lower page (the logical page addressed by the lower of the two addresses) is programmed first, followed by the upper page. When programming the upper page, programming voltages are applied to the same cells already storing valid data in the lower page. If power fails while the upper page is being programmed, data in that page is lost, and already‐stored data in the lower page is corrupted as well. When that lower page data is requested later by the host, the SSD will report the data irrecoverable.

Diese lower Page ist eben das ersten Bit der Zelle und die lässt sich schnell schreiben, dabei müssen die Ladungen nicht so korrekt eingebracht werden. Das schreiben der upper Page dauert dagegen länger, aber wenn man beides direkt aufeinanderfolgend macht, hat man die Daten noch im Cache und kann bei Fehlern die kompletten Daten woanders schreiben bzw. verliert bei einem Stromausfall nur die Daten, die gerade erst geschrieben werden sollten, was dann auch niemanden wirklich überrascht. Hat man aber die lower Page lange vorher geschrieben, stehen die Daten drin nicht mehr im Cache und auch in keinem Zusammenhang mit den aktuell geschriebenen Daten.

Ergänzung (15. März 2014)

Du bist verwirrt oder willst verwirren..

Nein, Du hast nicht verstanden, worum es geht, lies was ich eben zu Lower page corruption geschrieben habe, dann sollte es klar werden.

Bei TLC muss entsprechend öfter reorganisiert werden. Wann das geschieht, stand nicht zur Diskussion. Das ist egal. Das erhöhte Risiko bleibt gleich.

Nein, da bleibt kein höheres Risiko, wenn man es richtig macht, die Evos und als sehr zuverlässig bekannt. Wenn Blöcke gelöscht werden, müssen die noch gültigen Daten in den anderen Pages sowieso immer kopiert werden, daran ändert die Anzahl der Bit pro Zelle gar nichts.

 

[deodor]

Bei 3 verschiedenen Dateien in einem Block ist die Wahrscheinlichkeit höher, dass eine von 3 Dateien gelöscht und durch andere Daten ersetzt wird. Das solltest auch du begreifen.

 

[Hallo32]

Genau das passiert ja auch, aber nachher im Idle, wenn es nicht auf die Performance geht, Würde man es während des Schreibvorgangs machen, hätte man bessere Schreibraten wenn man auf den ganzen Trick gleich verzichten würde, denn das dauert natürlich auch entsprechend lange.[/URL]

Das Beschreiben des ersten Bits ist schneller, solange weniger als 50% der vollständig leeren Pages verwendet werden. Viele Nutzer geht es im Alltag eher um relativ kleine Datenmengen in Relation zum freien Speicherplatz, sas die SSD im Idle macht, interessiert die wenigsten.
Diverse Leute, die die Spiele mitschneiden, mal ausgeschlossen.

Oder fallen dir oft wiederholende Endanwender Szenarien ein, wo die ganze SSD in einen Rutsch beschrieben wird.

Das machen alle Controller, schalte mal den Schreibcache ab und schau Dir die 4k Schreibrate an, wenn die SSD ein sync.faking betreibt fallen die auf wenige MB/s zusammen. Aber das passiert in extrem engen Grenzen, zumindest bei SSD die keine Stützkondensatoren haben und wenn sie welche haben, darf die SSD auch sync-faking machen, sie kann die Daten ja noch aus eigener Kraft zurückschreiben. Das ist das gleiche wie bei RAID Controller mit oder ohne BBU.

Müsste ich einmal ausprobieren. -> Todo

Ergänzung (15. März 2014)

Das geht aber nur, solange wirklich nur ein Bit geschrieben wurde, eben wie es die Evo im TurboWrite Cache macht.

Das Ganze kann man auch mit einen GC Schritt verbinden.

1) Eine Page A lesen, die nur mit 1 Bit beschrieben wurde.
2) N-Pages lesen, die Daten beinhalten, die Aufgrund GC "verschoben" werden müssen und dnicht gelöscht werden dürfen, bis die maximale Anzahl der zu speichernden Bits pro Page erreicht wurden.
3) wie oben
4) wie oben
5) Page A und die N-Pages aus 2) für GC freigegeben.

Das "Kochrezept" ist immer identisch und wird wahrscheinlich bei allen "aktuellen" SSDs für die GC verwendet.

 

[Holt]

Bei 3 verschiedenen Dateien in einem Block ist die Wahrscheinlichkeit höher, dass eine von 3 Dateien gelöscht und durch andere Daten ersetzt wird. Das solltest auch du begreifen.

Bist Du der gleiche wie HWfan77 oder horban? Das scheint mir fast so.

Es ist egal, wie hoch das theoretische Risiko ist, es kommt auf dir praktische Umsetzung an und die ist bei den Samsung SSD mit TLC bisher absolut problemlos. Würde nur die Theorie eine Rolle spielen, hätte Intels 320er nie den 8MB Bug bekommen dürfen, den die Stützkondensatoren hätten verhindern müssen, aber in der Praxis ist der bei den Vorgängerversionen ohne diese Stützkondenstoren so extrem selten gewesen, dass er erst bei der 320er als richtige Bug erkannt wurde. Der 8MB Bug ist genau, das über Lower page corruption beschrieben wurde:

Loss of mapping information/Meta data information: Every SSD controller uses mapping information to translate from the host’s logical LBA addresses to physical flash memory locations. Mapping information must be created and maintained if the data is to be later retrieved from the drive, and must be updated whenever new data is written to a previously written LBA. If the mapping information is lost when power fails, the drive may show data corruption, deliver stale (corrupted) data or may not be capable of supporting logical I/O on the next power up.

Das erkennt man schon daran, dass die betroffenen SSDs nach einem Secure Erease wieder normal funktionieren. Die Logik dahinter ist auch klar, wenn sowieso alle Daten gelöscht werden, dann kann die korrupte Mapping Tabelle auch keinen Schaden anrichten und wird ja auch gelöscht, denn wenn die Indirection Table (FTL) nicht stimmt, denn würde es sonst Datensalat gehen und das gilt es in jedem Fall zu verhindern, also haben die FW Programmierer diesen 8MB Modus dafür vorgesehen, in dem man eben nicht mehr an die womöglich komplett unbrauchbaren Daten kommt.

 

[Hallo32]

Diese lower Page ist eben das ersten Bit der Zelle und die lässt sich schnell schreiben, dabei müssen die Ladungen nicht so korrekt eingebracht werden. Das schreiben der upper Page dauert dagegen länger, ...

Die Bezeichnung der Lower und Upper Pages muss ich mir in der ONFI Spec. mal nachschlagen. Falls es so realisiert ist, wie ich es mir gerade denke, würden die Daten beim zweiten Schreibzugriff nicht zerstört.

Ergänzung (15. März 2014)

@Holt

Stichpunkt: fehlerhafte FTL https://www.computerbase.de/news/storage/buffalo-ruestet-ssds-mit-st-mram-cache-aus.42790/

Was die wohl in ihren MRAM schreiben.

Ergänzung (15. März 2014)

Der 8MB Bug ist genau, das über Lower page corruption beschrieben wurde: Das erkennt man schon daran, dass die betroffenen SSDs nach einem Secure Erease wieder normal funktionieren. Die Logik dahinter ist auch klar, wenn sowieso alle Daten gelöscht werden, dann kann die korrupte Mapping Tabelle auch keinen Schaden anrichten und wird ja auch gelöscht, denn wenn die Indirection Table (FTL) nicht stimmt, denn würde es sonst Datensalat gehen und das gilt es in jedem Fall zu verhindern, also haben die FW Programmierer diesen 8MB Modus dafür vorgesehen, in dem man eben nicht mehr an die womöglich komplett unbrauchbaren Daten kommt.

Der 8MB Bug ist ein "nicht so feiner" Design Bug von Intel. Falls man nicht sicher ist, dass die neue Version zu 100% richtig geschrieben wurde, dann lässt man die Backup Version als gültig markiert. Das Überschreiben des Originals ohne eine Fallback Lösung ist nicht wirklich schlau.

 

[Holt]

Oder fallen dir oft wiederholende Endanwender Szenarien ein, wo die ganze SSD in einen Rutsch beschrieben wird.

Nein, deswegen schreibe ich ja auch immer, dass die Evo mit den 3 (6,/9/12) GB TurboWrite Cache für fast alle Schreibvorgänge ausreicht um diese massiv zu beschleunigen und auch wenn die Evo mit einer nicht konstant haltbaren Schreibrate beworben wird, es immer noch einen Unterschied zu den beworbenen Schreibraten der SSDs mit dem Sandforce ist, dessen beworbene Schreibrate man mangels extrem komprimierbarer Dateien im Alltag eben nie erlebt, oder hast Du Dateien wo nur 00 drin steht? Wenn, denn allenfalls welche die in Spare angelegt wurden, aber das sind wohl nur 0.x% der Schreibvorgänge, aber bei der Evo profitiert im Grund jeder Schreibvorgang, wenn das TurboWrite nicht gerade schon voll ist.

Müsste ich einmal ausprobieren. -> Todo

Die SSD mit dem Sandforce machen auch sync-faking, zumindest früher war es so, aber den vielen FW Updates, kann sich das geändert haben. Das dürfte daran liegen, dass der Sandforce ja auch als Enterprise Controller mit Unterstützung für Stützkondensatoren entwickelt wurde, nur ist dieses Feature den 25xx vorbehalten und dann dürfte die Datenkompression die Latenz noch weiter steigern, der würde ohne also wohl noch unter 1MB/s kommen. Nicht zuletzt gewinnt man mit sync-faking teils massiv Punkte in Benchmarks, darauf war der SF ja auch massiv optimiert.

Das Ganze kann man auch mit einen GC Schritt verbinden.

1) Eine Page A lesen, die nur mit 1 Bit beschrieben wurde.

Die sind nicht das Problem, das Problem dürften dann auftreten, wenn die zweite Page zu einer geschrieben wird, die ganz andere Daten hat und dann was schief läuft. Das Schreiben der zweiten Page an sich ist auch kein Thema, das wird es erst, wenn das nicht klappt, weil damit eben auch die Daten in der ersten Page beschädigt werden. Gehören beide aber nicht zusammen, hat man Daten einer ganz anderen Datei korrumpiert.

 

[Hallo32]

Die sind nicht das Problem, das Problem dürften dann auftreten, wenn die zweite Page zu einer geschrieben wird, die ganz andere Daten hat und dann was schief läuft. Das Schreiben der zweiten Page an sich ist auch kein Thema, das wird es erst, wenn das nicht klappt, weil damit eben auch die Daten in der ersten Page beschädigt werden. Gehören beide aber nicht zusammen, hat man Daten einer ganz anderen Datei korrumpiert.

Das spielt ja solange keine Rolle, bis die FTL auf die neue "Page" zeigt und dieser Schritt erfolgt in der Auflistung erst später und setzt ein erfolgreiches schreiben voraus.
Man darf nur nicht in die Original Page schreiben, sondern muss eine weitere als Ziel verwenden.

 

[Holt]

Wenn alles gut läuft, ist das alles kein Problem und wenn die Daten auf eine andere Page kopiert werden, was immer passiert wenn man die Daten ändert, wird immer die neue Page in der TFL dort eingetragen, nur muss auch die Indirection table immer wieder ins NAND zurückgeschrieben werden. Wenn das nicht korrekt passiert, weil eben z.B. der Strom plötzlich weg ist, dann hat man eben das Loss of mapping information/Meta data information Problem. Das hat aber nichts damit zu tun, wie bzw. wann man die lower und upper Page beschreibt.

 

[Hallo32]

Wenn das nicht korrekt passiert, weil eben z.B. der Strom plötzlich weg ist, dann hat man eben das Loss of mapping information/Meta data information Problem. Das hat aber nichts damit zu tun, wie bzw. wann man die lower und upper Page beschreibt.

Bevor dieses nicht passiert ist, werden die alten Pages nicht zum löschen freigeben und die alte Indirection Table nicht direkt überschrieben. Notfalls wertet der Controller einen primäre und sekundäre Indirection Table aus und verwirft die primäre, wenn der Hash nicht stimmt.
In der M4 scheint so etwas zu stecken. Die braucht nach einen harten Spannungsverlust länger zum initialisieren.

Somit bleibt dann nur eine Page, die als Leer gelistet wird aber schon beschrieben ist, als Folge eines Spannungsabfall. Das "Problem" lässt dich relativ einfach zu Laufzeit lösen. Nächste freie Page zum beschreiben verwenden und "schon volle" fürs GC eintragen.