SSDs und ihre Zuordnungstabellen - Technische Fragen

[Araska]

Hallo; vielleicht könnte jemand, der tiefer in der Materie steckt als ich, hier ein wenig Licht ins Dunkel der Arbeitsweise von SSDs bringen - ich lerne gern.

Um ihr Wear-Leveling zu ermöglichen, verfügen moderne SSDs über eine Tabelle, in der sie verzeuichnen, welcher logische Block welchem Block auf der SSD zugeordnet ist (Block hier aus Sicht der SSD als gemeinsam zu löschende/schreibende Einheit, nicht aus Sicht des Filesystems). Bei Schreibzugriffen weist die SSD dem zu schreibenden Block möglicherweise eine neue Adresse zu und vermerkt dies in ihrer Zuordnungstabelle.

So weit, so bekannt.

Geschieht das jedes Mal, oder hat die SSD interne Mechanismen (Use-Counter, Pseudozufall...) um festzustellen, daß ein Block mal wieder 'an der Reihe ist', eine neue Zuordnung zu bekommen'?

Die Zugriffstabelle wird (zumindest in Teilen) im DRAM der SSD ge-cachet; bei Ramlosen NVme bestht die Möglichkeit, einen (kleinen) Teil der Tabelle im Hauptspeicher des Hostsystems abzulegen.

Gehe ich zurecht davon aus, daß dieser Cache als Write-Through ausgeführt ist? Ein Write-Back hätte das Risiko, daß im Falle eines Stromausfalls die noch nicht zurückgeschriebenen Änderungen der Tabelle im RAM verlorengehen; das wäre ein ziemlicher Super-GAU. Ich kann mir ein Write-Back höchstens bei SSDs mit Pufferkondensatoren vorstellen, die dann bei Stromsausfall einen Emergency Shutdown durchführen...

Bei Write-Through (oder bei keinem Cache) wären das bei jeder Änderung der Zuordnungstabelle Schreibzugriffe auf den Flash; wie wird hier der Degradation vorgebeugt? Ich benötige einen Weg, beim Booten die Zuordnungstabelle zu finden, kann also die von ihr belegten Blöcke nicht in ihr selbst verzeigern...

Werden die Blöcke dieser Tabelle 'rollierend' mit Datestamp geschrieben (im reservierten Bereich) und die SSD sucht sich beim Bootvorgang die aktuellsten Blöcke heraus?
Wird diese Tabelle im Flash als Pseudo-SLC geschrieben, um die Lebensdauer der entsprechenden Zellen zu erhöhen?
Gibt es eine Art 'Indextabelle', die die Blöcke der Zuordnungstabelle enthält (wäre deutlich kleiner), und diese wird dann rollierend / als Pseudo-SLC abgelegt?

Bin ich auf einem kompletten Holzweg und mache mir Gedanken in die falsche Richtung?

 

[JumpingCat]

Es gibt SSD mit extra Hardware die für Stromausfälle gedacht sind. Die Kosten dann nochmal richtig extra Geld. Ansonsten weg ist weg. Der SSD RAM ist bei Stromausfall ansonsten genauso weg wie der normale RAM wo der HMB ist. Daher betreibt man Server auch mit USB und Dateisystemen die CoW haben wie zfs, NTFS, btrfs.

Die Details zu Wear Leveling sind die besten Geheimnisse der NAND Hersteller Hersteller. Da wirst du für aktuelle Technik kaum Details bekommen.

Die Blöcke werden sicherlich nicht mehr nur rollierend beschrieben, denke da auch noch interne Health Daten dazu die darüber entscheiden ob ein Bereich oder Chip "gesund" ist. Ich denke auch die einzelnen Chips dürften ein unterschiedliches Qualitätslevel haben.

 

[Simanova]

Hi,

die Firmware der SSD Controller merkt sich wie oft ein Block überschrieben wurde. Außerdem kann die Firmware Reserveblöcke aktivieren, um den Verlust defekter Blöcke auszugleichen. Desweiteren hat die Firmware immer eine API die mit dem Betriebssystem kommuniziert. Über diese API wird dann auch das block alignment gesteuert, damit bei Schreibvorgängen auch möglichst ganze Blöcke beschrieben werden (anstatt 2 Halbe).

Ganz früher zu Zeiten von Vertex2 wurde das Wear Leveling durch sequentielles Beschreiben gelöst. Also einfach drauf los schreiben der Reihenfolge nach. Das war im Jahr 2010. Seitdem hat sich viel getan. Leider gibt es zum genauen Funktionprinzip kaum Informationen, da das Betriebsgeheimnis der jeweiligen Firma ist. Dokumentiert ist lediglich die API von NVMe und es gibt allgemeine Informationen wie hier https://www.storage-insider.de/was-ist-wear-leveling-a-1048932/

Was den Cache betrifft so ist das System immer volatil. Einige SSD Hersteller haben kleine Kondensatoren drauf, damit bei einem Stromausfall die letzten Operationen abgeschlossen werden können und der Cache geleert ist. Wear Leveling Informationen werden im Normalfall immer als Metadaten im entsprechenden Speicherblock auf dem NAND Speicher abgelegt.

 

[KnolleJupp]

Wear-Leveling oder Verschleißnivellierung bedeutet das der Controller einer SSD versucht bzw. bestebt ist zu schreibende Daten in Speicherzellen mit dem niedrigsten Schreib-Zähler zu packen. Dabei gibt es verschiedene Herangehensweisen:

1. Der Controller berücksichtigt dabei nur freie Speicherbereiche, bereits belegte werden ignoriert.
2. Der Controller brücksichtigt auch bereits belegte Speicherbereiche. Ist der Schreib-Zähler einer Speicherzelle, die bereits Daten enthält, der niedrigste, werden die dort enthaltenen Daten in andere Speicherzellen verschoben und damit Platz für die neu zu schreibenden Daten geschaffen.
3. Der Controller schaut dabei nicht nur auf einzelne Speicherzellen, sondern betrachtet alle verfügbaren Speicherzellen und sorgt so dafür das der gesamte zur Verfügung stehende Speicherplatz möglichst gleichmäßig beschrieben wird.

Neben Wear-Leveling gibt es aber auch noch TRIM und Garbage Collection, die in Kombination dafür sorgen das die Speicherzellen einer SSD möglichst wenig und möglichst gleichmäßig abgenutzt werden. Und im Zweifel gibt es noch freie Reserve-Zellen, die in Anspruch genommen werden, falls doch mal eine Speicherzelle ausfallen sollte.

Garbage Collection sorgt im Hintergrund dafür das Daten so verschoben werden das es möglicht wenige nur teilweise beschriebene Blöcke gibt,
da nur blockweise gelöscht werden kann.

Der Speicher einer SSD ist aufgeteilt in Pages, Blocks und Planes.
Eine Page ist der kleinstmögliche Datensatz, der gelesen oder geschrieben werden kann, 4, 8 oder 16 Kibibyte groß.
Keine Ahnung wie die Größe bei aktuellen SSDs ist.
Ein Block ist eine Zusammenfassung mehrerer Pages, meist 128, 256 oder mehr Pages. Ein Block ist die kleinste Einheit, die gelöscht werden kann.
Daher der ganze Aufwand, durch TRIM, Garbage Collection usw. dafür zu sorgen das Blöcke möglichst vollständig mit Daten gefüllt oder geleert werden.

Mehrere Blöcke werden zu Planes zusammengefasst und mehrere Planes bilden letztlich den Speicherchip auf einer SSD.
Bei manchen Die-Shots eines solchen Speicherchips lassen sich die einzelnen Planes gut erkennen.

SSDs haben auch eine sogenannte Spare Area, das hat nichts mit Over-Provisioning zu tun.
Das ist ein Speicherbereich, der für das Betriebsystem unsichtbar ist und dieser Speicherbereich wird dann für solche Umverteilungen von Daten als Zwischenspeicher verwendet.

Wie nun das Wear-Leveling als in einen SSD-Controller einprogrammierten Algorithmus konkret arbeitet, ist Betriebsgeheimmnis der Controller-Hersteller.

 

[xxMuahdibxx]

Die Details zu Wear Leveling sind die besten Geheimnisse der NAND Hersteller Hersteller. Da wirst du für aktuelle Technik kaum Details bekommen.

Gibt für den prinzipiellen Ablauf Patente da alles dort ja gegen andere Firmen abgesichert werden muss.

Z.b. aber nur überflogen wir tiefgründig es ist keine Ahnung.

https://patents.justia.com/patent/12223172

 

[mae]

Details verraten die SSD-Hersteller nicht, also ist das, was ich hier schreibe, ein educated guess.

Ein wichtiger Aspekt, noch viel wichtiger als die Sache mit dem Wear leveling, ist, dass beim verwendeten NAND-Flash das Ueberschreiben einzelner logical Blocks nicht geht. Stattdessen werden grosse Segmente (blocks) geloescht, und dann kann man in einem geloeschten Segment Pages schreiben, die vielleicht noch immer groesser sind als ein logical block. Das bedingt eine aehnliche Verwendung wie bei einem log-structured file system (LFS), und daraus leitet sich folgendes ab:

Ja, ein geschriebener logical block wird jedes mal an eine andere Stelle geschrieben (und die alte Stelle wird dann als frei gemerkt).

Zum Thema Write-Through, Write-Back und Stromausfaellen: Es gibt SSDs mit "power-loss protection", und welche ohne. Was garantieren die ohne im Fall eines Stromausfalls, falls ueberhaupt? Man hoert aber nicht soviel ueber kaputte SSDs nach Stromausfaellen, also vielleicht machen sie doch etwas; eine Loesung waere z.B., dass das, was man nach einem Stromausfall von der SSD liest, vielleicht nicht der aktuelle Zustand ist. Aber dass einer der Zustaende, die logisch gesehen vor dem Stromausfall vorhanden war, nach dem Stromausfall als aktueller Zustand gezeigt wird. Alles, was danach geschrieben wurde und vielleicht unvollstaendig ist, wird dann als geloeschter Block markiert und ignoriert, bis das Segment erneut geloescht wird. SSDs mit Power-Loss-Protection wuerden dann tatsaechlich den juengsten logischen Zustand vor dem Stromausfall widerspiegeln. Aber nein, ich weiss nicht, ob die SSDs mit power-loss protection das garantieren.

Wenn die SSDs so etwas wie ein LFS implementieren, kann irgendwelche Meta-information auch einfach mit dem juengsten Segment mitgeschrieben werden. Das einzige Problem ist, dass ein LFS dabei klassischerweise immer wieder einen Zeiger auf die Wurzel des aktuellen Metadaten-Baums in den Superblock (bzw. mehrere, aber nicht sehr viele) geschrieben haben, und das geht bei SSDs wegen wear leveling nicht so ohne weiters. Ich kann mir dafuer verschiedene Loesungen ausdenken, weiss aber nicht, ob eine davon, oder etwas anderes in SSDs verwendet wird.

 

[mkossmann]

die Firmware der SSD Controller merkt sich wie oft ein Block überschrieben wurde

Diese Info reicht ja schon fürs Wearleveling. Beim Schreiben muss ohnehin der gesamte physische Block gelesen werden, dann wird modifiziert und dann zurückgeschrieben. Wenn man sich nun einfach eine Liste der (freien) Blöcke geordnet nach Anzahl der Schreibvorgänge anlegt und immer die Blöcke mit der geringsten Anzahl Schreibvorgänge fürs Rückschreiben benutzt hat man damit Wearleveling realisiert.
Der schwierige Teil ist dabei sicherzustellen, das gemerkte Anzahl von Schreibvorgängen und die Zuordnung von logischen zu physische Block auch bei Stromausfällen nicht ( auch nur teilweise) verloren geht

 

[Chuuei]

... daß im Falle eines Stromausfalls die noch nicht zurückgeschriebenen Änderungen der Tabelle im RAM verlorengehen; das wäre ein ziemlicher Super-GAU.

Genau das passiert aber. Das ist ein ganz übliches Fehlerbild mit denen die FW umgehen kann. Die Informationen lassen sich aus den zuletzt im Flash abgelegten Daten vollkommen rekonstruieren. Es kann in ungünstigen Fällen dann schon dazu kommen, dass alte Daten wieder auftauchen, welche eigentlich als gelöscht markiert wurden, aber die Information noch nicht vom RAM in den Flash geschrieben wurde. Im schlimmsten Fall sind die Verwaltungsdaten komplett korrupt und müssen wiederhergestellt werden.

Aus der Anfangszeit von SSDs stammt z.B. der Rat, SSDs wenn die nicht erkannt werden, halbe Stunde nur am Strom zu lassen (z.B. im BIOS Screen warten) und dann nach einem Reboot werden diese erkannt. Das behebt genau das oben genannte Fehlerbild. Verwaltungsdaten korrupt, also meldet sich SSD nicht am System, aber unter Strom kann die den Flash scannen und die Daten neu aufbauen und nach einem Reboot ist die dann normal da. Bei neueren SSDs mit hohen Densities kann die Zeit auch mittlerweile viel länger sein.

Da die Hersteller mit der Zeit natürlich auch gelernt haben damit umzugehen, ist die Menge an Informationen, die beim Sudden Powerloss verloren gehen meist überschaubar.

Es gibt SSDs mit "power-loss protection", und welche ohne. Was garantieren die ohne im Fall eines Stromausfalls, falls ueberhaupt? Man hoert aber nicht soviel ueber kaputte SSDs nach Stromausfaellen, also vielleicht machen sie doch etwas; eine Loesung waere z.B., dass das, was man nach einem Stromausfall von der SSD liest, vielleicht nicht der aktuelle Zustand ist. Aber dass einer der Zustaende, die logisch gesehen vor dem Stromausfall vorhanden war, nach dem Stromausfall als aktueller Zustand gezeigt wird.

Genau, sobald die Daten mit den Informationen aus dem Flash rekonstruiert wurden, hat man quasi den alten Stand. Problem ist, dass es dabei auf unterster Ebene zu Datenkorruption kommen kann. Von z.B. 4KB Daten welche gerade geschrieben werden beim Stromausfall, wurden vielleicht 2KB geschrieben, 1KB war noch nicht geschrieben und der Rest war dann schon wieder geschrieben, weil es vielleicht parallel auf einen anderen Flash Die geschrieben wurde.

In der Praxis ist das für den normalen User meist nicht tragisch. Wenn der einen Film von A nach B kopiert und das System dabei abschmiert, dann kopiert der die Daten halt nochmal, macht sich aber nicht die Mühe zu gucken bis auf welches Byte der Film kopiert wurde.

In anderen Fällen wie z.B. Datenbankservern ist das dagegen ein großes Problem und daher gibts dort die Hardware mit eingebauter PLP. Alles was inflight ist wird sicher in den Flash geschrieben. Ja, die Datenübertragung wird dann natürlich immer noch unterbrochen wenn das System abschmiert, aber man weiß ganz genau bis zu welchem Byte die Daten geschrieben wurden und vor allem sind bis dahin auch garantiert alle Daten konsistent.

Diese ganze Problematik mit dem DRAM Cache ist übrigens der Grund, warum es z.B. im Industrie, NetCom etc. Markt unzählige SSDs ohne DRAM gibt. Man spart sich so viele mögliche Fehler.