News SSD-Cache-Problem: Trotz Flush droht Datenverlust bei Stromausfall

[foofoobar]

Solche Annahmen sind problematisch. Wer sagt, dass das OS das wirklich auslöst? Guck dir einfach an wieviel dutzende Sonderbehandlungen es im Linux Kernel für einzelne Devices gibt, sogar für spezifische Device und Host Kombinationen. Da ist ohne Einblick überhaupt nicht klar, welche Features wirklich genutzt werden.

https://linux.die.net/man/2/fsync

fsync() transfers ("flushes") all modified in-core data of (i.e., modified buffer cache pages for) the file referred to by the file descriptor fd to the disk device (or other permanent storage device) so that all changed information can be retrieved even after the system crashed or was rebooted. This includes writing through or flushing a disk cache if present. The call blocks until the device reports that the transfer has completed. It also flushes metadata information associated with the file (see stat(2)).

 

[Chuuei]

Die Essenz von meinen Aussagen ist eigentlich, dass man dem SW Stack nicht blind vertrauen sollte wenn man sich so weit aus dem Fenster lehnt und den Herstellern Versagen unterstellt aber selbst auch nicht die Möglichkeiten hat das wirklich auf HW Ebene zu klären.

siehe z.B. hier: fsync() does not flush all the file

Von der Problembeschreibung genau das gleiche was der Autor hier jetzt festgestellt hat, und das schon vor 10 Jahren...

Create a file
Write around 40KB of data on it
Flush it using fsync() or fdatasync()
Close it
Then I power-cut the system within a couple of seconds: result: the end of the file is missing on disk.

Und was war das Problem hier? Dieser Fragende hatte Funktionen aus der fread/fwrite Familie genutzt die nen Cache im Userspace nutzen aber nicht fflush benutzt. Ohne diesen Aufruf sieht der Kernel die Daten gar nicht und fsync hat einfach nichts was es flushen kann. Führt genau zu diesem Fehler was der Autor auf Twitter schildert, hat aber nichts mit irgendwelchen Device Problemen zu tun. Und das blöde ist auch, das das ganze durch unterschiedliches Zeitverhalten verschiedener Devices zu unterschiedlichen Ergebnissen führen kann. Ich hab die Tweets durchgeguckt aber nicht gefunden, wie der Autor sein Testcode genau ausschaut. Wenn ich da was übersehen habe, gerne her damit.

 

[Piktogramm]

@Chuuei
Ja, wenn du Zitate von Spezifikationen solang zusammenstreichst, bis sie das Gewünschte ergeben, kommst du auch zu solchen Aussagen -.-
Der Wichtige Teil ist halt schon, dass die Daten geschrieben und der Vorgang bestätigt werden muss. Das einfach wegzulassen ist ein klein wenig fahrlässig.
Und auf die Schnelle finde ich keine Sonderbehandlung im Linux Kernel, der auf eine Sonderbehandlung des Flush Commands hindeutet. Wenn irgendwer sowas vorschlagen würde, würde Linus mal wieder starke Meinungen vertreten und im Zweifelsfall das Laufwerk einfach auf eine Blacklist werfen.

Ergänzung (25. Februar 2022)

@Chuuei die Zweite, der Zitatblock zu den 40KB Daten bezieht sich glaube auf Hectors Versuche unter MacOS, wo er lernte, dass fsync unter MacOS und Linux ein dokumentiert anderes Verhalten haben. Darüber meckert auch Niemand in Bezug auf die Zuverlässigkeit der Laufwerke.

Edit:
UND die Dritte, genau lesen ist auch nicht so deins... Bei dem Eintrag in der Maillinglist den du gefunden hast kommt am Schluss raus, dass fsync() an der Stelle nicht greift, da sqlite fwrite/fread nutzt/nutzte, was ein fflush() erforderlich macht, bevor der Kernel über fsync geschrieben Daten schreiben kann.

 

[Luthredon]

Wobei mittlerweile schreibt, dass er da irgendwas automatisiert hat, ohne genauere Angaben zu machen was er da aufgebaut hat.

Na dann sind wir uns ja doch einig .

Manuelle Tests haben den Nachteil, dass Menschen langsam sind. Ein Flush der SSD im aktuellen M1 Macs ist mit 20ms schon richtig langsam, aber weit unter dem was Menschen an Reaktionszeit haben. Wenn man da manuell die Spannung trennt, nachdem eine Meldung auf einem Bildschirm aufpoppt, so haben SSDs locker 100ms zum Schreiben von Daten. Also aus Sicht von Computern unheimlich viel Zeit um zu verschleiern, dass der zu testende Flusch als erfolgreich gemeldet wurde, obwohl dem nicht so war.

Ich weiß nicht, warum du dich so am Timing 'verbeißt'. Nochmal: vereinfacht wird ja behauptet, dass trotz erfolgter Flush-Meldung, der Cache nicht geflushed ist. Das aber ist ein timing-unabhängiger Fehler. Insofern ist deine obige Beschreibung zwar völlig richtig, aber für das Problem irrelevant.

 

[Chuuei]

Edit:
UND die Dritte, genau lesen ist auch nicht so deins... Bei dem Eintrag in der Maillinglist den du gefunden hast kommt am Schluss raus, dass fsync() an der Stelle nicht greift, da sqlite fwrite/fread nutzt/nutzte, was ein fflush() erforderlich macht, bevor der Kernel über fsync geschrieben Daten schreiben kann.

Du hast recht und was noch viel besser ist - ich auch, genau das hab ich nämlich geschrieben und ich würde es echt toll finden bevor man einen Beitrag komplett liest bevor man persönlich wird. Ich zitiere mich mal selber:

Und was war das Problem hier? Dieser Fragende hatte Funktionen aus der fread/fwrite Familie genutzt die nen Cache im Userspace nutzen aber nicht fflush benutzt. Ohne diesen Aufruf sieht der Kernel die Daten gar nicht und fsync hat einfach nichts was es flushen kann.

Wer hat hier also nicht gelesen?

 

[Piktogramm]

@Luthredon
Jain, Zwischen erfolgter Meldung eines erfolgreichen Flushes und dem Wegnehmen der Versorgungsspannung vergeht Zeit. Innerhalb dieser Zeit hat ein Laufwerk die Chance Daten vom Cache zu persistieren. Je mehr Zeit vergeht, desto höher ist die Chance, dass das Fehlverhalten nicht mehr nachweisbar ist. Entsprechend wichtig ist das Timing zwischen erfolgter Rückmeldung vom Flush und dem Trennen der Spannung. Diese Zeit sollte möglichst kurz sein und wenn man vergleichbare Tests haben will auch möglichst mit geringem Jitter.

@Chuuei
Du widersprichst dir in deinem eigenem Post

Von der Problembeschreibung genau das gleiche was der Autor hier jetzt festgestellt hat, und das schon vor 10 Jahren...

Der fflush()-Sachverhalt hat halt nichts mit dem zu tun was Hector festgestellt hat noch die darauf anschließenden Tests von Bishop zum Verhalten von NVMe Flush. Und es hat auch nichts mit "aber was wäre wenn, der Kernel komische Sachen macht".

Wie auch immer, für mich ist die Nacht vorbei. Nächtle

 

[Quonux]

if (firmware is trash) then {data is trash};

ist eigentlich nichts neues.
Eine Liste mit Modellen mit guter Firmware wäre hilfreich.
Dann gäbe es Druck auf die Hersteller was immer gut ist.

 

[Luthredon]

Jain, Zwischen erfolgter Meldung eines erfolgreichen Flushes und dem Wegnehmen der Versorgungsspannung vergeht Zeit.

Zweifellos

Innerhalb dieser Zeit hat ein Laufwerk die Chance Daten vom Cache zu persistieren. Je mehr Zeit vergeht, desto höher ist die Chance, dass das Fehlverhalten nicht mehr nachweisbar ist.

Was meinst du mit 'persistieren'? Der Flush-Vorgang ist ja keine einzelner Aktion zwischen Controller und Flash (also dem eigentlichen IC). Das 'umfüllen' des RAMs ins Flash ist sicher ein repetiver Prozess in Blöcken o.ä., wobei jede einzelne Schleife das Timing des Flashes beachten muss. Danach ists geschrieben und fertig. Wenn alles drin ist, ists ganz fertig. Warum soll danach noch Zeit nötig sein, für was auch immer?

Entsprechend wichtig ist das Timing zwischen erfolgter Rückmeldung vom Flush und dem Trennen der Spannung. Diese Zeit sollte möglichst kurz sein und wenn man vergleichbare Tests haben will auch möglichst mit geringem Jitter.

Kommt darauf an, was man herausfinden möchte. Ich halte es aber für ziemlich sinnlos, einen Test zu machen, wie lange man aufgrund einer fehlerhaften 'Fertig-Meldung' noch warten müsste, bis der Flush-Vorgang wirklich fertig ist. Selbst wenn man davon ausgehen kann, dass ein Mensch immer relativ lange braucht, bis er auf eine Meldung reagiert, wäre solch eine SSD nie z.B. in einem NAS verwendbar.

Aber vielleicht reden wir auch aneinander vorbei, weil ich deinen Hinweis auf möglichste Jitterfreiheit gar nicht verstehe .

 

[jit-010101]

Ehrlich?

Bei mir hängt jedes System hinter einer USV.

Die die es nicht tun, haben selbst Akkus (Notebooks, Tablets) oder können über Backups schnell ersetzt werden.

Ach Backups, wer braucht schon Backups.

(Nicht nur) SSDs müssen immer ganzheitlich betrachtet werden. z.B. werden die letzten Samsung NVMe-Reihen verdammt warm. Würde ich mir persönlich nicht in's Boot holen.

Gibt wenig gute Quellen die z. B. wirklich die Performance der Controller benchmarken mit unterschiedlichen Bedingungen um über Benchmark-Modi relevante Daten hinauszukommen und eine Idee zu bekommen wie die Teile in der Realität laufen.

Gerade die SK Hynx Gold P31 ist da eigentlich wirklich gut in Gesamtbild.

Wenn ich zusätzliche Stromausfallsicherheit brauche dann kaufe ich gleich SSDs aus dem Enterprise-Sektor mit entsprechenden Hardware-Lösungen. Alles andere ist doch Quatsch ...

 

[massaker]

...SSDs müssen immer ganzheitlich betrachtet werden. z.B. werden die letzten Samsung NVMe-Reihen verdammt warm. Würde ich mir persönlich nicht in's Boot holen....

Schreibst Du aus 2019/2020? 2 Jahre in die Vergangenheit gereist? Gerade "die letzten Samsung NVMe-Reihen", also 980Pro und vor allem die 980 non-Pro sind vergleichsweise kühl und unproblematisch.
"verdammt warm" passt auf das davor, vor allem auf die 970EVO Plus.

 

[Piktogramm]

@Luthredon

Was meinst du mit 'persistieren'? Der Flush-Vorgang ist ja keine einzelner Aktion zwischen Controller und Flash (also dem eigentlichen IC). Das 'umfüllen' des RAMs ins Flash ist sicher ein repetiver Prozess in Blöcken o.ä., wobei jede einzelne Schleife das Timing des Flashes beachten muss. Danach ists geschrieben und fertig. Wenn alles drin ist, ists ganz fertig. Warum soll danach noch Zeit nötig sein, für was auch immer?

Für einen Testfall, der kontrollieren soll, ob Laufwerke zurecht oder fälcherlicherweise Flusches quittieren gilt folgendes Vorgehen:

• Schreibzugriff mit Flush
• Flush bestätigt bekommen
• Speicher von Spannungsversorgung trennen

Der Zeitraum zwischen dem 2. und 3 Schritt ist der Punkt, wo es beim Test auf den Zeitbedarf ankommt. Dieser Zeitbedarf, für den ich den Englischen Begriff Timing nutzte ist kritisch für reproduzierbare Tests. Diese Zeit sollte nach Möglichkeit klein sein und wenn man den Test wiederholt sollte diese Zeit zudem konstant sein (ergo, geringes Jitter).

Das Zeitverhalten der Flashchips ist an der Stelle egal, da sollte der Controller der SSD sowieso alles abstrahieren. Bei NVMe ist ja vorgesehen, dass das Hostsystem dem Speichercontroller simple Kommandos gibt, der Controller kümmert sich um alle Spezifika und quittiert über NVMe nur Erfolg/Miserfolg.

Kommt darauf an, was man herausfinden möchte. Ich halte es aber für ziemlich sinnlos, einen Test zu machen, wie lange man aufgrund einer fehlerhaften 'Fertig-Meldung' noch warten müsste[...]

Der Test ist ja nicht "wie lange müsste man warten", sondern OB NVMe von Laufwerken als erfolgreich quittiert wird, obwohl es nicht stimmt. OB dem so ist, erkennt man jedoch um so besser, je weniger Zeit zwischen der Quittung für NVMe Flush und dem Trennen der Energieversorgung des Laufwerks geht.
Deswegen sind Menschen schlechte Komponenten von solchen Tests, Fleischklopse sind zu langsam

 

[Luthredon]

OB dem so ist, erkennt man jedoch um so besser, je weniger Zeit zwischen der Quittung für NVMe Flush und dem Trennen der Energieversorgung des Laufwerks geht.

Ich kürz das mal ab, weil ich endlich verstanden habe, um was es dir geht . Insofern ja, man 'erwischt' potentiell mehr SSDs bei dem Fehler, je schneller man zwischen Schritt 2 und 3 ist. Aber nur, wenns diesen eigentlich logischen Fehler (Kauslität umgedreht, erst Meldung, dann Ereignis), tatsächlich bei mehreren SSD mit unterschiedlichem Timing gibt.

Deswegen sind Menschen schlechte Komponenten von solchen Tests, Fleischklopse sind zu langsam

Wie gesagt, das kommt darauf an, was man finden möchte oder muss.

Du kannst mühelos ein System bauen, das feststellt, dass es keine 1000 Tastenbetätigungen über eine PC-Tastatur ins Gerät bringt. Aber ist das relevant? Ist eine Tastatur deshalb fehlerhaft, die eigentlich für den menschlichen Finger gemacht ist? Deshalb ja meine Frage, was hat der gute Herr Bishop eigentlich testen wollen? Boah ... ich hab jetzt gerade keine Lust, das nochmal zu lesen .