Flash-Grundlagen, Teil 3: Firmware-Architekturen

Moderne SSDs mit PCIe-4.0-Schnittstelle protzen mit Schreibraten von mehr als 7 GByte/s. Doch lange halten sie das nicht durch: Wenn ihr Cache voll ist, dann sinkt die Geschwindigkeit schnell auf die Hälfte oder gar noch weniger. Im letzten Teil unserer Serie zu den Flash-­Grundlagen wollen wir uns näher mit dem Beschreiben des Flash-Speichers beschäftigen und klären, wo die Herausforderungen liegen und warum ein Cache die Lebensdauer der SSD reduzieren kann.

Aus Kostengründen verbauen die Hersteller heute in den allermeisten SSDs und anderen Flash-Produkten 3D-TLC-­Speicher mit 3 Bits Speicherkapazität pro Zelle. Im Unterschied zu den früher verwendeten planaren 2-Bit-Typen gibt es dabei Unterschiede in der Ansteuerung.

Bei den älteren Flash-Typen mit Floating Gate mussten die Controller noch mindestens zwei separate Programmierschritte erledigen. Mit der Einführung von Charge Trap bei 3D-TLC-Flash [1, 2] schreiben die SSD-Controller die drei Bits pro Zelle in einem einzigen Programmiervorgang. Da sich eine logische Page-­Größe von 16 KByte etabliert hat, bedeutet dies, dass der Flash-Controller nun 48 KByte im RAM halten muss – multipliziert mit der Anzahl der parallel geschalteten Dies und Planes. Gerade ältere und kleinere Controller etwa für USB-Sticks oder SD-Karten verfügen nicht über ausreichend RAM, um diese Datenmenge aufzubereiten und können daher TLC-­Speicher nicht direkt beschreiben.

Neue Fehlerquellen

Mit der Einführung von TLC-Zellen und 3D-Bauweise kamen neue Fehlerquellen hinzu. Durch die hohen für die Programmierung benötigten Spannungen kann es zum Versagen von chipinternen Isolationsschichten oder Leiterbahnen kommen. Während des Löschens eines Blocks treten zwar noch höhere Spannungen und Ströme auf als beim Programmieren, jedoch ist hierbei ein Ausfall des Blocks unproblematisch, da die Daten im betroffenen Block ohnehin nicht mehr benötigt werden.

Beim Programmieren jedoch kann ein solches Versagen zum Verlust sämtlicher Daten in bereits programmierten Pages dieses Blocks führen. Damit der Ausfall eines Blocks nicht zum Datenverlust führt, nutzen die Hersteller verschiedene Techniken.

Oder besser gesagt: Sie sollten sie einsetzen. Bei einem 32-GByte-USB-Stick für zwei Dollar aus dem Online-Shop im fernen Asien ist dies nicht zu erwarten. Wie aber bereits in den beiden vorangegangenen Teilen gezeigt, sollte man USB-Sticks sowieso kein großes Vertrauen entgegenbringen.

Generell ist aber der Ausfall von mehreren Blöcken während der SSD-Lebensdauer einkalkuliert, der Firmware stehen entsprechend Reserveblöcke zur Verfügung. Zum Schutz vor Blockausfällen kommen verschiedene Verfahren zur Anwendung:

Bei TLC direct + Read Verify hält der Controller die Daten aller noch nicht vollständig gefüllten Blöcke in einem DRAM-Chip. Sind die Blöcke voll, prüft der Controller die Daten. Kam es beim Programmieren zu einem Blockausfall, sind die Daten noch vorhanden und der Controller kann sie in einen anderen Block schreiben. Wegen des hohen DRAM-Speicherbedarfs ist die Umsetzung dieses Verfahrens nur mit Controllern möglich, die externes DRAM unterstützen und damit relativ teuer sind. Read Verify kommt daher nur bei SSDs zum Einsatz, nicht jedoch bei USB-Sticks sowie CF- und SD-Karten.

Bei TLC direct + Block Parity deckt man den Ausfall eines Blocks in einem Blockverbund durch Redundanz ab. Dafür existiert auch der Begriff Block-RAID, da das Prinzip einem RAID 5 bei Festplatten ähnelt. Bei diesem Verfahren schreibt der Controller die Parity-Informationen aller anderen Blöcke in den letzten Block eines Blockverbundes. Fällt nun einer dieser Blöcke aus, lässt sich die Information ­jederzeit wiederherstellen. Ein Prüflesen direkt nach dem Programmieren ist nicht erforderlich. Der Vorteil dieses Verfahrens liegt neben der hohen Schreibgeschwindigkeit darin, dass die Daten zusätzlich nach dem Ende des Schreibvorgangs gut geschützt sind. Bei nach diesem Verfahren arbeitenden Speichermedien steigt die ­Zuverlässigkeit.

Die Zuverlässigkeit lässt sich durch die Speicherung der Parity-Information in einem seperaten Die noch weiter erhöhen. Ein Defekt in einem mehrfach genutzten Logikteil wie einem Adressdecoder oder einer Ladungspumpe führt dann zwar zum Totalausfall eines Dies, dies lässt sich ­jedoch immer noch kompensieren. Eine solche Implementierung ist dann bis auf die fehlende Redundanz des Flash-Con­trollers identisch zu einem RAID 5. Aufgrund der Zusatzkosten für das zusätzliche Die findet sich diese Implementierung bisher nur bei sehr großen Kapazitäten im Enterprise-Bereich.

Das Block-Parity-Verfahren ist zudem nur bei neueren Controllern möglich, die über eine zusätzliche Hardwareeinheit für die Parity-Berechnung verfügen. Eine ­Berechnung und Verwaltung in Software wäre zu langsam.

Bei pSLC First + Read Verify speichert der SSD-Controller die Daten zunächst in im pSLC-Modus betriebenen Blöcken, er nutzt dabei also nur jeweils ein Bit pro Zelle. Da die Spannungen im pSLC-Modus viel geringer sind, ist die Wahrscheinlichkeit eines Block-Ausfalls extrem gering, Schutzmaßnahmen sind also nicht notwendig. Zu einem späteren Zeitpunkt ­kopiert der Controller die Daten dann im TLC-Modus in andere Blöcke. Kommt es beim Programmieren der TLC-Blöcke zu einem Defekt, wird dieser spätestens beim anschließenden Prüflesen entdeckt – die Daten sind in den pSLC-Blöcken noch vorhanden. Dieses Verfahren wird von allen Controllern verwendet, die keinen DRAM und keine Hardware-Einheit für Block ­Parity haben. Es ist somit auch das einzige Verfahren für ältere Controller zur Ansteuerung von Charge Trap Flash.

Gelegentlich kommen auch Kombinationen vor. Alle Verfahren haben Vor- und Nachteile, so ist für TLC direct teurer DRAM nötig. Bei SSDs, die bereits mit einem DRAM als Schreib-Cache und als Lese-Cache für die internen Verwaltungsdaten bestückt sind, muss dieser für Read Verify etwa doppelt so groß ausfallen.

Kapazitätseinbußen

Bei Block Parity geht ein Teil der Bruttokapazität für die Parity-Information verloren. Eine 1-TByte-SSD enthält beispielsweise 16 Dies mit 3D-TLC-Flash von je 512 GBit. Zum Erreichen einer hohen ­Geschwindigkeit beim sequenziellen Lesen und Schreiben werden je nach Leistungsfähigkeit des Controllers mehrere Planes parallel betrieben. Wenn in diesem Beispiel 16 Planes logisch zusammengeschaltet sind, verliert man 6,25 Prozent der Gesamtkapazität für die Parity-Information.

Beim Einsatz der pSLC-First-Strategie geht ebenfalls ein Teil der Kapazität für den pSLC-Bereich verloren. So benötigt man für beispielsweise 20 GByte pSLC-­Cache das Dreifache, also 60 GByte TLC-Flash. Damit sinkt die TLC-Kapazität deutlich. Da wegen der geringeren Programmierspannung im pSLC-Modus der Verschleiß der Zellen viel geringer ist als im TLC-Modus und sich die zwei Zustände von pSLC zuverlässiger unterscheiden lassen als die acht Zustände bei TLC, ist die Lebensdauer von Zellen im pSLC-Modus 10- bis 30-fach so hoch wie im TLC-Modus. Im Umkehrschluss müssten mindestens zwischen 10 und 3,3 Prozent der TLC-­Kapazität als pSLC zur Verfügung stehen, damit der kleinere pSLC-Bereich nicht schneller als der TLC-Bereich altert und dadurch die Lebensdauer der SSD begrenzt

Bei einer Brutto-TLC-Kapazität von 1000 GByte würden bei 10 Prozent pSLC-Anteil 769 GByte auf Blöcke im TLC-Modus entfallen und 231 GByte auf Blöcke im pSLC-Modus, was 77 GByte pSLC-Speicherkapazität entspräche (231 GByte / 3 = 77 GByte). Bei 3,3 Prozent ­würden 910 GByte für den TLC-Bereich verbleiben (bei 30 GByte pSLC-Speicherkapazität). Da eine hohe Kapazität werbewirksam ist, wird der pSLC-Bereich meist kleiner gewählt, als er sein sollte.

Hinzu kommt, dass bei Einzelarbeitsplätzen die meisten Schreibzugriffe auf wenige Adressen entfallen. Dadurch sind Daten im pSLC-Bereich zum Teil schon vor dem Transfer in den TLC-Bereich veraltet, wodurch der Schreibzugriff auf den TLC unterbleibt, der kleine pSLC-Bereich schneller altert als der TLC-Bereich und somit die Lebensdauer der SSD sinkt.

Bei Benchmarks tritt dieser Effekt beim JEDEC-Client-Workload auf, der einen typischen Einzelarbeitsplatz simuliert und somit weitestgehend nur den pSLC-Bereich altern lässt. Ein zu klein dimensionierter pSLC-Bereich und die hohe zeitliche und räumliche Lokalität der Datenzugriffe führen dazu, dass der pSLC-Bereich deutlich stärker beansprucht wird.

pSLC first und Block Parity sind somit der Grund, weshalb viele SSDs keine „runden“ Kapazitätsangaben haben, sondern beispielsweise 960 GByte Speicherkapazität.

pSLC als Cache

Ein positiver Nebeneffekt der pSLC-­First-Strategie ist der enorme Geschwindigkeitsgewinn beim Schreiben kleiner ­Datenmengen. Das Programmieren der Zellen im pSLC-Modus geschieht viel schneller als bei TLC, da keine Gefahr ­besteht, bei zu schnellem Programmieren am gewünschten Zustand (der Anzahl der Elektronen) vorbeizuschießen.

Die Daten werden dann meist ein paar Sekunden später in den TLC-Bereich kopiert, wenn die SSD gerade keine Kommandos des Betriebssystems verarbeiten muss. Wenn das Betriebssystem aber eine größere Datenmenge schickt, bricht die Schreibgeschwindigkeit nach dem Befüllen des pSLC-Bereichs massiv ein. Denn jetzt muss der Controller erst wieder Daten aus dem pSLC-Cache lesen und in den TLC-Bereich kopieren. Anschließend überprüft der Controller die Daten im TLC-Bereich und erst dann gibt er wieder pSLC-Blöcke frei, um weitere Daten vom Betriebssystem aufzunehmen.

In Benchmarks, bei denen die geschriebene Datenmenge größer ist als der pSLC-Bereich, würde das Speichermedium daher sehr schlecht abschneiden. Einige Hersteller tricksen hierbei und schreiben – sobald der pSLC-Bereich voll ist und die Firmware wegen sequenzieller Zugriffe einen Benchmark zu erkennen glaubt – die Daten nur noch im TLC-direct-­Modus, obwohl die SSD weder ein Read Verify durchführt noch über Block Parity verfügt.

Wandelbare Blöcke

Wegen des offensichtlichen Geschwindigkeitsgewinns haben einige SSDs einen pSLC-Bereich, der nur als Cache dient. Diese Medien stellen die Ausfallsicherheit durch Block Parity sicher und verwenden den pSLC-Cache nur als Puffer. Ist der Puffer voll, wechselt die SSD auf TLC direct und leert den pSLC-Cache erst, wenn sie nicht mehr ausgelastet ist.

Um die hohe Schreibgeschwindigkeit möglichst lange zu halten, verwenden viele SSDs einen dynamischen pSLC-­Cache. SSDs mit Dynamic-pSLC-Cache nutzen maximal den gesamten freien ­Speicher im pSLC-Modus. Erst wenn mehr Speicherplatz benötigt wird, als im pSLC-Modus zur Verfügung steht, werden Daten in den TLC-Modus umkopiert. Je mehr ungenutzte Kapazität zur Verfügung steht, desto länger kann das Medium die hohe pSLC-Schreibgeschwindigkeit beibehalten. Mussten die Daten noch nicht in den TLC-Bereich umkopiert werden, profitiert man auch beim anschließenden Lesen von der hohen pSLC-Geschwindigkeit und der geringen Latenz – dies wird man jedoch wohl nur in Benchmarks feststellen können.

Das Betriebssystem informiert eine SSD regelmäßig per TRIM-Kommando über Bereiche, die von gelöschten Dateien belegt sind (siehe Kasten auf dieser Seite). Das erleichtert die Arbeit der Garbage-­Collection-Funktion der SSD und reduziert den Zellverschleiß, da keine bereits gelöschten Dateien – also eigentlich leere Datenbereiche – verschoben werden müssen, um neue leere Blöcke zu generieren.

Bislang spezifiziert kein NAND-Hersteller den Verschleiß der Zellen im pSLC/TLC-Mischbetrieb. Entsprechend kommen hauptsächlich zwei verschiedene Strategien zur Kontrolle der Zellabnutzung zur Anwendung:

• Der dynamische Modus, also die Verwendung als pSLC-Bereich oder der Wechsel zwischen pSLC und TLC, wird nach wenigen hundert Zyklen eingestellt und es verbleibt nur ein kleiner statischer pSLC-Teil, der weiterhin als ­pSLC-First oder -Cache verwendet wird. Der Nachteil dieser Methode ist der plötzliche Geschwindigkeitsverlust, der für die gesamte Restlebensdauer anhält. Der Vorteil (für den Hersteller der SSD) ist das besonders gute Abschneiden bei Benchmarks, da dabei üblicherweise fabrikneue SSDs zum Einsatz kommen und nur ein Bruchteil der Kapazität getestet wird.

• Das Programmieren und Löschen eines Blocks sowohl im TLC- als auch im pSLC-Modus wird als ein TLC-Zyklus gezählt, obwohl der Verschleiß bei einem pSLC-Zyklus geringer ist als bei einem TLC-Zyklus. Da das Schreiben im pSLC-Modus die dreifache Menge an Blöcken belegt, erreicht die SSD schneller die spezifizierte Anzahl an Zyklen und muss früher als notwenig ausgetauscht werden.

Dennoch muss diese Lösung im Endeffekt, also bei der erreichbaren Ausdauer, nicht schlechter abschneiden als eine SSD mit viel zu klein dimensioniertem pSLC-First-Bereich.

Ausblick

Für Server und Industrieanwendungen ist in den meisten Fällen TLC direct die richtige Wahl für SSDs. Verschleiß und Performance lassen sich gut vorhersagen und das Betriebssystem stellt ohnehin einen Cache im Arbeitsspeicher bereit. Einzelarbeitsplätze profitieren von einer SSD mit pSLC-Cache, der das kurzzeitige Hantieren mit größeren Datenmengen beschleunigt. Dynamic-pSLC-Cache spielt seine Stärken bei Speichermedien mit geringer Belegung voll aus. Dort zeigt diese Strategie eine sehr gute Performance, die aber entweder nicht für die gesamte Lebensdauer bestehen bleibt oder die Ausdauer reduziert. pSLC-first hat seine Daseinsberechtigung nur bei älteren Controllern und Medien mit ­kleinen Kapazitäten, bei denen sich Block Parity nicht einsetzen lässt und ein DRAM zu teuer wäre. (ll@ct.de)