News Dauerschreibtest: Sechs NVMe-SSDs schaffen 1,5 Petabyte

Meine ersten beiden SSDs, Vertex 2 mit 64GB, beide nach kurzer Zeit am Controller-Bug verstorben. Alle anderen leben noch.
 
Irgendwie interessant wie wenig die Leute so auf SSD schreiben hier. Ist da irgendwie optimiert worden? @ssh @deo
Meine evo ist da noch vergleichbar, aber auf die schreibe ich auch gezielt wenig. System ja, Auslagerungsdatei reduziert und geteilt, Spiele usw woanders. Selbst meine Screenshots landen nicht auf C.
32 GB RAM hilft auch dass wenig in die Auslagerungsdatei geschrieben wird.
2021-12-05 16_20_31-CrystalDiskInfo 8.12.13 Shizuku Edition x64_s.png

2021-12-05 16_20_39-CrystalDiskInfo 8.12.13 Shizuku Edition x64_s.png


Die 840 Pro wurde dagegen weniger geschont. Nur als Systemplatte nach den ersten 10 defekten Sektoren rum ersetzt.
32 Farben in den Screenshots sind btw absicht
 
Rickmer schrieb:
Das halte ich derweil für Fehlinterpretation der Daten.
Korrekt

Der Grund dafür ist relativ einfach zu verstehen:

Gesetzt in dem folgenden Beispiel: Pagesize 4k, Blocksize 265k (Hier mal nen Link zu nem beliebigen SLC NAND Flash von Kioxia aus dem die Beispielzahlen sind)

Szenario 1 mit 100% 4k random Writes:
Der User schreibt 4k Daten und die landen in einer Page in Block 1. Dafür muss der ganze Block vorher gelöscht werden. Nun schreibt der User die nächsten 4k Daten und die landen in einer Page in Block 2. Die FW macht das so, da sie Block 1 nicht löschen will um PE Cycles zu sparen. So gehts dann weiter. Das führt dazu, dass 256k/4k = 64 Blöcke genutzt werden müssen für 256k Daten.

Szenario 2 mit 100% 16k random writes:
Vorgehen wie oben, 16k in den ersten Block, 16k in den zweiten Block etc. Also brauchen wir dann am Ende 256k/16k = 16 Blöcke.

Und siehe da, 16k random Writes brauchen nur ein Viertel der Blöcke gegenüber 4k oder umgekehrt, man darf mit 16K viermal soviel schreiben im Vergleich zu 4k um auf die gleiche Menge PE Cycles zu kommen. Und das entspricht auch genau dem was wir z.B. im Micron Datenblatt sehen welches ihr besprochen habt. Mit 4k darf man 5% der Gerätekapazität pro Tag schreiben und mit 16k 20% - also genau die 4 fache Menge wie oben gezeigt.

Die 5% bzw. 20% als Wert wiederum kommen zustande aus der verfügbaren Menge an PE Cycles die für den Flash erlaubt ist, aufgeteilt auf die Menge der Tage in 5 Jahren.

Die einfache Erklärung zeigt aber auch schon, wie wenig dieser Wert für die Praxis erstmal aussagt. Komplett weggelassen habe ich was z.B. passiert wenn Daten geschrieben werden die nicht in einen Block passen, wenn Pages aus verschiedenen Blöcken zusammengefasst werden im Rahmen des GC, wenn das Device ziemlich voll ist, etc. Durch die Tatsache, dass immer ein ganzer Block gelöscht werden muss bevor dort auch nur eine einzelne Page geschrieben werden kann, ergibt sich immer Mehrarbeit gegenüber dem was der User verlangt. Selbst in einfachen Szenarien kommt es vor, dass z.B. für 10GB geschriebene Daten vom User aber 15GB im Flash geschrieben werden müssen durch umsortieren der Pages etc. Das ist der Write Amplification Factor (WAF). (Der hier im Beispiel mit 1.5 noch recht niedrig ist)

Niemand hat jetzt genau solchen einfachen Szenarien. Daher hat z.B. die JEDEC Szenarien spezifiziert um eine gewissen Vergleichbarkeit zu haben. Diese werden meist als Client/Workstation/Server Workload bezeichnet und unterscheiden sich darin wieviele und in welchen Größen Daten sequentiell und random geschrieben werden. Die gleiche SSD kann z.B. im Client Workload nen WAF von 2 haben und im Server Workload von 20. Heißt im Serverworkload hält sie nur ein zehntel so lang wie im Client Workload. Daher geben Consumer SSDs auch nur einen Wert an - natürlich den für sie günstigsten ;)

Und um damit mal ein wenig auf das Artikelthema zurückzukommen. Unterschiedliche SSDs haben bei gleichem Workload durch Unterschiede in der FW auch unterschiedliche WAFs. Der Artikel vergleicht die Haltbarkeit der SSD vom User aus gesehen, aber im Prinzip könnte es sein, dass bei den 1.5 PB Daten vom Host geschrieben SSD1 z.B. 2 PT Daten im Flash geschrieben hat und SSD2 aber schon 3 PB Daten, einfach weil der WAF unterschiedlich ausfällt. Sowas würde mich z.B. aus technischer Sicht auch noch interessieren bei solchen Tests.

Aber ja, Lebensdauerbetrachtungen bei einer SSD sind ziemlich kompliziert :)
 
  • Gefällt mir
Reaktionen: Rickmer
Gut das die Adata XPG 2TB nicht getestet wurde. Nach 26TB war schluß. Hab Sie durch ne Samsung ersetzt. Adata kauf ich vorerst nicht mehr :)
 
mindfest schrieb:
Gut das die Adata XPG 2TB nicht getestet wurde. Nach 26TB war schluß. Hab Sie durch ne Samsung ersetzt. Adata kauf ich vorerst nicht mehr :)
die ADATA XPG SX6000 Pro 2TB? fand die ganze interessant... 5j garantie und ne riesen TBW. klar nicht die schnellste aber das kann ich eh meistens nicht ausnutzen...
 
wuesty schrieb:
die ADATA XPG SX6000 Pro 2TB? fand die ganze interessant... 5j garantie und ne riesen TBW. klar nicht die schnellste aber das kann ich eh meistens nicht ausnutzen...
Hi,

genauer gesagt wars die 2000GB ADATA XPG SX8200 Pro PCIe M.2 (NVMe) ASX8200PNP-2TT-C.
 
Meine Crucial m4 128GB hat mittlerweile auch schon 1,1PB seit 2011 runterschreiben müssen. Läuft immer noch wie am ersten Tag. Wäre auch nicht schlimm wenn sie abraucht, als Arbeitslaufwerk wird sie mehrmals am Tag voll geschrieben und wieder gelöscht. Als Lagerstätte für sensible Daten würde ich sie jetzt auch nicht mehr einsetzen.
 
  • Gefällt mir
Reaktionen: Corpus Delicti und Grimey
Mir ist in all den Jahren noch nie eine SSD kaputt gegangen, ich kann mich nicht mal an einen defekten USB-Stick erinnen und die Teile vergesse ich gerne mal in Hosen in der Waschmaschine.
Der imaginäre Stapel defekter HDDs wäre hingegen beachtlich, erst vor 2 Wochen musste ich mal wieder eine WD Red in meinem NAS ersetzen.
 
Zurück
Oben