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