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

[I'm unknown]

Immer wenn ich OC settings probiert hab und mein PC gecrasht ist hatte ich nachher Probleme mit der Windows Installation.

Gerade bei RAM OC gelangen auch mal gerne korrupte Daten vom RAM auf den Festspeichermedien. Das hat mit dem Flush aber eher weniger am Hut.

 

[Piktogramm]

Ich schreibe die ganze Zeit nur von fsync() als Linux/Posix API-Call[1] und vom NVMe-Flush Command

Der Bezug auf einzelne Programmiersprachen wäre mit auch zu anstrengend. Ob nun fflush() unter C oder os.fsync() unter Python ist im Endeffekt ja auch egal, da die ja auch "nur" die APIs vom Betriebssystem nutzen.
[1] Ohne jedesmal MacOS und BSD-Derivate zu differnezieren

 

[mae]

Der Bezug auf einzelne Programmiersprachen wäre mit auch zu anstrengend. Ob nun fflush() unter C oder os.fsync() unter Python ist im Endeffekt ja auch egal, da die ja auch "nur" die APIs vom Betriebssystem nutzen.

Nur macht fflush() in C eben kein fsync(), sondern ein write(); wenn Du fsync() willst, musst Du das nachher noch explizit aufrufen. Aber zumindest mir war klar, dass es in der urspruenglichen Meldung nicht um fflush() ging.

 

[Luthredon]

bitte was ?? 🤭 das ist jetzt nicht dein Ernst, oder ?

Ich glaube, er verwechselt das mit dem 'Parken' der Köpfe. Das wird tatsächlich mit der Restenergie des Spindelmotors erledigt.

@topic: Ich verstehe die Diskussion hier nicht ganz. Ihr redet von Datenbanken, plötzliche Stromausfällen etc. So wie ich den Artikel verstanden habe, bzw. die 'Entdeckung' von Bishop, gehts aber um normales Handling. D.h. wenn der Cache eigentlich leer sein sollte, ist er es nicht. Das wäre aber ein massiver Controllerfehler, der jeden jederzeit treffen könnte, der z.B. eine ext. SSD verwendet!

Eine externe nVME z.B. sollte ja vorm 'Abziehen' logisch ausgeworfen werden (gerade bei MacOS, das immer nörgelt, wenn mans nicht tut). Damit wird eben sichergestellt, dass flüchtiger Cache-Inhalt aufs Flash geschrieben wird. Wenn das passiert ist, gibts eine Rückmeldung vom SSD-Controller und man kann die SSD abziehen. Wenn das nicht funktionieren würde, würde man jedesmal Daten verlieren.

Soll ich das glauben, dass dies bei den getesten SSD nicht funktioniert? Ich hab davon noch nie gehört, geschweige denn Ähnliches erfahren. Mir fehlen in dem Artikel jegliche Testparameter. Von Statusabfragen etc. ist dort nämlich nicht die Rede. Dafür von '... Daten normalerweise nur kurz im Cache ...". Heißt das, der gute Bishop hat nach x Sekunden mal den Strom abgezogen, weil 'normalerweise' die Daten dann safe sein sollten? Außerdem würde ich erwarten, dass die Controller (die alleinigen 'Verantwortlichen' für die Cache Strategie) genannt werden. Die Angaben über die betroffenen SSD sind höchst nebulös! Und welches Interesse hat eigentlich Apple an der Entdeckung? Niemand glaubt hoffentlich, dass ein Apple Entwickler irgendetwas veröffentlich, was nicht mit Apple abgesprochen ist.

Sorry, ich finde den Artikel seltsam. Fakt ist jedenfalls, dass ich sämtliche Arten von SSDs (auch viele externe) verwende und noch nie Daten verloren habe, wenn die SSD 'gesagt' hatte, alles ist geflushed. Oder versteh ich das alles falsch?

 

[Flare]

Vielen Dank für die sehr brauchbaren Infos:
Posts: #38 +#39
Elandion + Piktogramm
👍

 

[Piktogramm]

[..]
Ich hab davon noch nie gehört, geschweige denn Ähnliches erfahren. Mir fehlen in dem Artikel jegliche Testparameter. Von Statusabfragen etc. ist dort nämlich nicht die Rede. [...]

Von irgendwas noch nicht gehört zu haben ist meist eines der sinnlosesten Argumente. Die aller meisten Menschen werden davon noch nichts gehört haben. Der Kreis jener, die auf einer Ebene entwickeln, bei der das NVMe-Protokoll relevant ist, ist sehr klein.
Und Testparameter sind halt NVMe Flush erzwingen, auf Bestätigung warten und händig Strom abziehen (was der SSD unglaublich viel Zeit gibt) und danach schauen ob die geschriebenen Blöcke intakt sind oder nicht.
Fundierte, reproduzierbare und vor allem automatisierbare Tests sind das nicht. Ganz ohne Witz, so sehen viele "Proof of Concepts" auf den Tischen von Entwicklern aus.

Und bei Apple, die Entwickler der Kernelfunktionen unterliegen gar nicht so harten Maulkörben, deren Code ist öffentlich und bei den Gremien für PCIe, NVMe etc. wird ja sowieso teilöffentlich mitgewirkt.

 

[Boimler]

Hier gab es in letzter Zeit recht häufig Stromausfälle. Am schlimmsten war es Mitte des letzten Jahres, wo hier abends dreimal der Strom für fünf Minuten oder am Ende eine halbe Stunde wegbrach. An meiner Arbeitsstelle hatten wir das Problem zum Glück bisher nicht. Da hat der Austausch einer defekten USV zuletzt einen Monat gedauert. Hat in der Verwaltung niemanden interessiert, weil "es läuft ja alles auch ohne USV". Genau die Argumente, die hier diskutiert werden, ziehen da natürlich nicht, weil sich ein Nicht-ITler Datenverlust nur sehr abstrakt vorstellen kann. Waren sehr nette Gespräche...

 

[foofoobar]

Von irgendwas noch nicht gehört zu haben ist meist eines der sinnlosesten Argumente. Die aller meisten Menschen werden davon noch nichts gehört haben. Der Kreis jener, die auf einer Ebene entwickeln, bei der das NVMe-Protokoll relevant ist, ist sehr klein.
Und Testparameter sind halt NVMe Flush erzwingen, auf Bestätigung warten und händig Strom abziehen (was der SSD unglaublich viel Zeit gibt) und danach schauen ob die geschriebenen Blöcke intakt sind oder nicht.
Fundierte, reproduzierbare und vor allem automatisierbare Tests sind das nicht. Ganz ohne Witz, so sehen viele "Proof of Concepts" auf den Tischen von Entwicklern aus.

Ich würde mir einfach mehr Tests in dieser Richtung wünschen.

Evtl. findet sich ja ein Adapter von hier: https://geizhals.de/?cat=hdadko&sort=p&xf=11184_M.2+PCIe~11189_PCONE wo die Stromversorgung durch eine einfache Modifikation unterbrechbar ist. Und beim testen kann/sollte man auch auf ein Filesystem verzichten.

 

[Piktogramm]

@foofoobar
Müsste halt mal jemand machen. Platine entwerfen, bestücken lassen und ein Programmschreiben, welches nach erfolgreichem fsync() einen GPIO-Pin nutzt um die Spannungsversorgung zu kappen. Das sind so Dinge, die simpel klingen, vergleichsweise simpel sind und dann doch ganz fix eine Woche dauern.
Es fängt ja schon damit an, dass die meisten Mainboards keine GPIO-Pins haben und Parallelports meist auch nicht.

 

[rg88]

Das ist doch ein Firmwareproblem?
Wieso schickt das Gerät die Meldung, dass der Flush durchgeführt ist, wenn die Daten gar nicht persistiert wurden? das klingt doch eher als wäre der Code so:

do_flush(){
sendFlushSuccessful();
writeCacheToFlash();
}

 

[Tom_111]

Wer sich bei Stromausfall auf der sicheren Seite fühlt ist immer auf dem Holzweg. Wem Sicherheit wichtig ist betreibt als Backup ein externe USV Stromversorgung… alle anderen sollten damit leben dass es „sein kann“ dass sicher geglaubte Daten vllt nicht mehr da sind ( vor allem wenn man mit den Daten gearbeitet hat in dem
Momement)

Die originalen Daten bleiben erhalten. Nur die editierte Datei geht verloren.

 

[Nagilum99]

Wer sich bei Stromausfall auf der sicheren Seite fühlt ist immer auf dem Holzweg.

Nur dass Stromausfall nichts mit dem hier geschilderten Problem zu tun hat. Der ist auch ohne Flush problematisch, auch bei HDDs.

 

[Luthredon]

Von irgendwas noch nicht gehört zu haben ist meist eines der sinnlosesten Argumente.

Seh ich nicht so, wenn es um eine banale Funktion geht, die milliardenmal am Tag benutzt wird.

Die aller meisten Menschen werden davon noch nichts gehört haben. Der Kreis jener, die auf einer Ebene entwickeln, bei der das NVMe-Protokoll relevant ist, ist sehr klein.

Woraus liest du, dass es bei dem Artikel A) ums NVMe-Protokoll geht und B) ums Timing. So wie ichs verstanden hab, postuliert der Mann grob gesagt, dass der Cache nicht wirklich geleert ist, obwohl das Flag, oder eine Bestätigung das Gegenteil anzeigt. Dass es dabei um Timing geht hab ich nirgends gelesen.

Und Testparameter sind halt NVMe Flush erzwingen, auf Bestätigung warten und händig Strom abziehen (was der SSD unglaublich viel Zeit gibt) und danach schauen ob die geschriebenen Blöcke intakt sind oder nicht.

Wie gesagt, wie genau hats dann der Herr Bishop gemacht? Ich sagte ja, vielleicht hab ich was übersehen, aber genau so hab ich das verstanden.

Fundierte, reproduzierbare und vor allem automatisierbare Tests sind das nicht.

Sondern?

Und bei Apple, die Entwickler der Kernelfunktionen unterliegen gar nicht so harten Maulkörben, deren Code ist öffentlich und bei den Gremien für PCIe, NVMe etc. wird ja sowieso teilöffentlich mitgewirkt.

Naja, bekannter Code sicher. Aber wenn Apple an etwas für die Zukunft arbeitet, hat sogar der Reinigungsdienst ein NDA .

 

[Piktogramm]

@Luthredon
Die Nutzung allein ist sehr weit davon entfernt es auch nur ansatzweise zu verstehen, wie etwas funktioniert. Selbst beim Betrieb von Servern gehen Fehleranalysen oft nicht so tief, als dass solche Fehler auffindbar wären. Sowas fällt kaum auf, wenn nicht gerade jemand wie Hector Martin versucht Linuxtreiber für PCIe/NVMe für Apple M1 Macs zu schreiben.

Und woher ich weiß, dass es um NVMe Flush und Timing geht? Ich verfolge was Hector mit seinem Projekt treibt und habe das auf Twitter verfolgt und Vorwissen ist auch da.. Ansonsten macht der Artikel es auch sehr einfach:

Fun story: I tested a random selection of four NVMe SSDs from four vendors. Half lose FLUSH’d data on power loss. That is the flush went to the drive, confirmed, success reported all the way back to userspace. Then I manually yanked the cable. Boom, data gone.
— Russ Bishop (@xenadu02) February 21, 2022

Es steht lesbar im Artikel
Wenn man dann mal den Link zu eben jenem Bishop folgt kann man auch lesen was der so getrieben hat. Dieses Internet mit diesen Links ist da voll praktisch.. Wobei mittlerweile schreibt, dass er da irgendwas automatisiert hat, ohne genauere Angaben zu machen was er da aufgebaut hat.

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.

 

[orodigistan]

wenn dieen jetztnur ein paar minuten alt sind ist das nicht schlimm für mich. was.mich nervt sind die dass alte daten beschädigt werden können wie kernel treiber und so. dass man ein neues laufwerk kaufen muss

 

[C4rp3di3m]

Hmm okay...

Also gut wenn man ein PSU hat was noch etwas Überbrückt und hoffen dass es gereicht hat, oder wie?
Ein plötzlicher Stromausfall sorgt immer für Kaos, richtig geil wenn im Betrieb gerade alle CNC Fräsen und Drehmaschinen am Werken sind #kenn ich!

Zuhause kommt zwar selten vor, aber 2021 hatte ich zwei mal kurz den Strom weg, passiert ist zum Glück nichts. Außer PC wurde nicht Ordnungs..blabla Runtergefahren Meldung halt.
NVME ist bei mir aber noch nicht C: da ich nach 6 Monaten idle der M2 noch zu Faul bin Win10 neu zu installieren dugg

mfg

 

[LuckyMagnum]

Klingt erst mal nicht gut. Kann nur hoffen, dass meine Samsung-SSDs weiterhin okay bleiben. Allen Anderen wünsche ich natürlich gute und schnelle Behebung dieses Problems (evtl. durch ein FW-Update?)

 

[ssh]

Sicherlich nicht schön aber wie oft ist denn bei euch der Strom ausgefallen?

Bei mir? Notebook noch nie. PCs an Standorten mit instabilem Stromversorgung sind mit USVs abgesichert und an anderen Standorten liegt der letzte Stromausfall schätzungsweise 20 Jahre zurück.

Letztes Jahr im Sommer 2021 gleich mehrfach durch Unwetter. Da durfte so mancher ITler Überstunden schieben trotz oftmals USV.

 

[CodeZero1990]

...Dann bau ich mir wieder eine Festplatte ein ^^

 

[Bonanca]

Ich dachte der Hauptanwendungszweck des DRAM-Caches ist zum bereithalten der FTL?
Über welche Datenmengen reden wir hier bei einem Flush?
Ist das ein reines NVMe-Problem oder kann das auch bei SATA passieren?