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

[joshy337]

"[..] und lässt sich nur durch Stützkondensatoren verhindern, wie sie aber nur bei einigen Enterprise-SSDs vorhanden sind."

Tja, warum die wohl dort verbaut werden?
Geiz ist halt doch nicht geil.

Den Preis um 5€ erhöhen und ein paar Kondensatoren hinzufügen und gut ist's.
Wenn es garnicht anders geht, die Mehrkosten einfach an den Endkunden weitergeben.

Der zahlt ja ohnehin einen unnötigen Aufpreis wegen der Profitmaximierung seitens der Hersteller und Lieferkette, so oder so.

Wäre nur zu fair, wenn er dafür wenigstens was erhält, was die Daten nicht verliert.

Falls das nicht geht, wegen dem Konkurrenzkampf.. Dann wünsche ich mir ein Gesetz wie die Dgstvo, die allen Herstellern verbindlich vorschreibt, dass Stützakku/-Kondensator nun Standard sind.
Beim Glühbirnenverbot und dem Ladekabelzwang ging's ja schließlich auch und zwar EU-weit.

 

[Hito360]

hier wird gnadenlos übertrieben um "Recht zu haben"


Wenn ein Stromausfall kommt merkt das die SSD sicherlich eh nicht rechtzeitig um einen Flush auszuführen (oder doch?) - Wie oft wird by default überhaupt geflusht?

Ergänzung (23. Februar 2022)

Geiz ist halt doch nicht geil.

liegt bestimmt nicht daran, dass die meisten User(vor allem auf CB ) immer nach dem besten PreisLeistungsverhältnis schauen um 10x5€ zu sparen und damit dann ne RGB Leiste zu kaufen

 

[joshy337]

Das hat nichts mit Kondensatoren zu tun. Ein Flush muss ja bestätigt werden, egal ob es Kondensatoren gibt oder nicht. Das Verhalten ändert sich nicht durch Kondensatoren!

Das ergibt schon Sinn, ja.
Der Witz an der Sache ist halt nur..

a) Linux/Unix leben historisch bedingt in einer idealen Welt, in der es keinen unerwarteten Shutdown gibt. Daher die gute Unterstützung für UPS aka USV Geräte mit Bleiakkus. Nur, Privatanwender haben so was nicht (ich bin eine Ausnahme).

b) Enterprise-SSDs die in Systemen mit USV im Einsatz sind, haben trotzdem Stützkondensatoren. Warum?

c) SSDs sind dabei, die Festplatten zu ersetzen.
Nur, Festplattenlaufwerke haben Restschwung und können noch ein paar Daten sichern, wenn der Strom ausfällt.
SSDs sollten diese Fähigkeit auch haben. Daher: Stützkondensatoren

Ich gebe zu, ich bin kein Experte auf dem Gebiet.
Aber: Ich habe bereits Stromausfälle am PC miterlebt.
Linux damals mit EXT1/2 ohne Journaling war eine Katastrophe. Verlorgengegangene I-Nodes ohne Ende.

Beim Mac (9/X) ohne aktiviertes Journaling (älteres Versionen des HFS) war es fast genauso schlimm.

Windows 9x mit FAT/FAT32 hatte dagegen nur wenig Datenverlust. Verlorenen Ketten, die per ScanDisk oder CheckDisk (CHKDSK /F) gesichert wurden.

Mit Windows XP und insbesondere NTFS mit seinem Journaling hatte ich gute USV-Unterstützung ubd praktisch keinen Datenverlust.
Auch ohne USV.

 

[Piktogramm]

@Hito360
Eine essentielle Eigenschaft von Computern ist Determinismus. Wenn ein Verhalten definiert wurde, muss sich daran gehalten werden!
Wie häufig Flushes sind, kommt auf das Anwendungsprofil drauf an. Tendenziell sind es aber alle Anwendungen, die genau auf Datenintegrität achten müssen. Datenbanksysteme, Backupsoftware, Verwaltungsaufgaben auf Dateisystemen.

 

[NOTAUS]

Also im Prinzip das Phänomen, was man beim Verschieben von Daten auf einen USB- Stick oder SD- Karte kennt. Windows meldet "Vorgang fertig", die Dateien sind schon im Ursprungsordner gelöscht, aber der Stick blinkt immer noch fröhlich vor sich hin, da die Daten noch unterwegs sind und der Schreibvorgang noch nicht abgeschlossen ist.

 

[Piktogramm]

@joshy337
Im Enterprisesegment wird man nicht für jede Aktion einen Flush verlangen, sowas kostet viel zu viel Performance. Anderseits will man genauso wenig, dass Laufwerke kreatives Verhalten an den Tag legen, wenn man einen Flush erzwingt.
Auch wenn im Zweifeslfall "nur" Randfälle wirklich kritisch sind, will man sowas nicht.

 

[hans_meiser]

Gut, das sowas von jemandem geprüft wird. Es ist sehr ärgerlich, Daten zu verlieren oder eine ganze OS Installation neu aufspielen zu müssen.

Es gilt allerdings auch nach wie vor: wichtige Daten muß man halt separat absichern, am besten außerhalb des Hauses. Und jeder, der einen PC professionell einsetzt, sollte sich eine ordentliche USV leisten und diese auch entsprechend warten. Mit diesen Absicherungen sollte man wirklich keine wichtigen Daten einfach verlieren können, bzw. das Problem Stromausfall sollte halt dann kein Problem mehr sein.

 

[GrumpyCat]

Wenn ein Stromausfall kommt merkt das die SSD sicherlich eh nicht rechtzeitig um einen Flush auszuführen (oder doch?) - Wie oft wird by default überhaupt geflusht?

Es geht eher darum, dass Dateisystem und Datenbanken ähnliche Mechanismen als Write Barrier benutzen. Ansonsten schreibt die Platte/SSD/NVMe die Daten nämlich die ganze Zeit in der Reihenfolge, die ihr gerade am besten passt (siehe Native Command Queueing), und das will man nicht immer, z.B. wäre es schon schön, wenn die Metadaten zu einer Datei ("es wurden 1MB Daten an Datei X angefügt") erst dann tatsächlich geschrieben werden, wenn die eigentlichen Daten auch auf Platte sind, und nicht andersherum (ansonsten hat man nach einem Absturz im Beispiel 1MB Datenmüll an der Datei, der a) niemals so geschrieben wurde und b) potenziell sensitive Daten aus anderen Teilen des Dateisystems enthält). Bei Metadaten-Aktualisierungen der Art "Datei X liegt jetzt wegen Copy-on-Write an anderer Stelle auf dem Datenträger" wird das noch viel spaßiger, falls die Reihenfolge nicht eingehalten wird.

 

[pvcf]

Nur, Festplattenlaufwerke haben Restschwung und können noch ein paar Daten sichern, wenn der Strom ausfällt.

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

 

[mae]

Ich wette aber auch drauf, dass diverse SSDs bei (häufigem) plötzlichen Stromverlust nicht nur die beschriebenen Probleme haben, sondern u.U. auch den kompletten Inhalt schrotten. Der ganze Krams mit Erase Block Mapping etc. ist einfach relativ komplex, und die Firmwares werden sicher nicht alle Fehlerpfade speziell bei seltenen Problemen wie plötzlichem Stromausfall mitten in hohem Schreib-Load korrekt behandeln.

Dieses Problem gibt es seit Jahrzehnten (natuerlich diesseits von SSDs), und dafuer gibt's auch schon seit Jahrzehnten Techniken wie z.B. Journals, die gar nicht so kompliziert sind. Man muss halt nur Leute fuer die Firmware engagieren, die sich damit befassen und das eben so implementieren, dass es funktioniert, und mit diversen Techniken (ob jetzt Fuzz-Testen mit simulierten Stromausfaellen oder mit formaler Verifikation, am besten wohl beides) sicherstellt, dass sich kein Implementierungsfehler einschleicht.

Und es braucht offensichtlich auch Kunden, die das Testen und die schlechten Hersteller blossstellen, sonst haben wir den Effekt, dass schlechte Produkte die guten dank niedrigerer Entwicklungskosten niederkonkurrenzieren.

@Holindarn: Die betroffenen Hersteller lassen durch ihre schleissige Entwicklung ihre Kunden in's offene Messer rennen, da finde ich eine Schonzeit voellig unangebracht, hier geht's ja nicht um eine Sicherheitsluecke, die ein Angreifer ausnutzen koennte, bevor der Hersteller das repariert. Im Gegenteil muss sowas schnellstmoeglich bekannt werden, damit die Kunden moeglichst schnell ihre SSDs ersetzen und/oder ihre Backup-Plaene ueberarbeiten.

 

[Bigeagle]

Das ist so uncool dass man sich plötzlich mit Haarspaltereien befassen müsste.
Macht das OS nur ein einfaches sync beim shutdown?
Macht die SSD selbst beim poweroff signal ein sicheres sync?
Oder kann ein bloßes herunterfahren unter umständen schon reichen wenn irgendwelche zeiten nicht den schätzungen der SSD Hersteller genügt?

So ganz klar ist mir das nicht. Sollte mich im normalfall auch nicht jucken, dafür gibts doch die entsprechenden funktionen zum synchronisieren der speicher.

Ich verstehe das Problem nicht ganz.
Bzw das Problem schon, aber die Auswirkungen sollten ja vernachlässigbar sein.

Abgesehen vom klassischen Stromausfall und sei es nur der Nachwuchs der entdeckt hat dass die Büroklammer in die Steckdose passt - es kommt schon mal vor dass man den PC hart ausschaltet. Da wünscht man sich schon dass nicht noch Daten von vor 3 Tagen im Cache rumgammeln.
Im zweifelsfall fehlt dann eben mal was und die Partition wird nicht mehr erkannt. Stell dir vor dein Windows macht updates und crasht dabei. Danach sind dann in irgendeiner dll ein teil der Updates schon geschrieben worden und ein Teil ist mit dem Cache verschwunden. Spaßige Windowsreparatur, yay.

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

3 mal elektrisch aus Sicht des PC, aber je nachdem muss man bei freezes auch mal hart ausschalten. Bei einem Freund sorgt Board oder Graka für sporadische crashes bei denen es nicht mal zum bluescreen reicht. Der PC erlebt bestimmt 30-40 'stromausfälle' im Jahr. Da will man schon dass nicht nur das Dateisystem wieder konsistent wird, sondern auch nicht mehr als die ungespeicherte Arbeit verlieren. Wenn dabei das was man vor 5 Stunden gespeichert hat verloren geht weil ein Teil des journals noch im Cache rumgammelt wäre das sehr doof.
Und wenn man schon kein flush ordentlich durchführt, warum dann nicht gleich ganz ohne barriers arbeiten bis zum shutdown? nur ein warmer cache ist ein guter cache. Falls die Motivation eine leistungssteigerung war und es nicht einfach nur ein übersehener Fehler ist.

 

[entropie88]

https://twitter.com/marcan42/status/1494213855387734019

Macht Apple bei allen seinen neuen M1 Geräten auch.

 

[mae]

b) Enterprise-SSDs die in Systemen mit USV im Einsatz sind, haben trotzdem Stützkondensatoren. Warum?

Weil auch USVs und Netzteile ausfallen koennen. Ok, jetzt kannst Du noch redundante Netzteile zusammen mit redundanten USVs verwenden, aber wir machen das nicht.

Nur, Festplattenlaufwerke haben Restschwung und können noch ein paar Daten sichern, wenn der Strom ausfällt.

Laut allem, was ich davon gehoert habe, wird der gerade geschriebene Block fertiggeschrieben, danach laesst die Platte das sicherheitshalber bleiben. Und ich hatte auch schon den Fall, wo bei einer schwankenden Stromversorgung zwei Platten (des selben Modells) eines RAID1 beide nachher Lesefehler hatten, seither kaufen wir immer verschiedene Platten und verschiedene SSDs fuer unsere RAIDs.

 

[Piktogramm]

@entropie88
Du solltest vielleicht alles lesen. Grundsätzlich ging Hector davon aus, dass MacOS sich bei fsync() wie Linux verhält und einen NVMe-Flush auslöst. Das mach MacOS nicht und das ist so dokumentiert. Es braucht F_FULLSYNC() unter MacOS um Flushes auszulösen. Jedoch ist die SSD der Macs unsäglich langsam, wenn man dies tut.
Naja und daraufhin ging die Testerei los, was andere SSDs so machen, wenn man es darauf anlegt.

 

[Denniss]

Also normal sollte der DRAM-Cache bei SSD so konzipiert sein das dort überhaupt keine Nutzerdaten stehen sondern nur ein Kopie des Flash Transaction Layer. Speziell bei Modellen mit HMB ist der Cache so klein das er eigentlich nur für Teile des FTL reicht.
Scheinbar sind einige Firmwares unsauber programmiert bzw irgendwas funktioniert da nicht richtig.

 

[Haldi]

Ich wette die WD Black sn850 tut das auch!
Immer wenn ich OC settings probiert hab und mein PC gecrasht ist hatte ich nachher Probleme mit der Windows Installation.
Mit der SATA SSD ist das nie passiert. Aber die NVME PCI-E hat SEHR viele Probleme verursacht die nicht nachvollziehbar waren und auch über Checkdisk oder so nicht auffindbar.
Half nur komplett löschen und Windows neu aufsetzen.

 

[andr_gin]

Bei einem Datenbanksystem ist das ein Supergau.
Die Entscheidung wann ein Flush notwendig ist und wann nicht liegt beim Programmierer der Software. Falls dieser einen Fpush Befehl sendet, so muss dieser auch auf jeden Fall durchgeführt werden. Das ist vollkommen inakzeptabel wenn diverse Firmwareentwickler dies aus Kostengründen einfach weglassen.

Ich würde mir hier wirklich mehr unabhängige Tests in die Richtung wünschen. Dann weiß man als Käufer welche SSDs man kaufen kann und bei welchen Herstellern man in Zukunft die Finger weglassen muss.

 

[.Snoopy.]

Bisher als M2 immer die Samsung 970 Evo Plus empfohlen und verbaut. Also wie es aussieht alles richtig gemacht. Ich denke, dass die normale 980er aufgrund des anderen Aufbaus Daten verlieren wird. Bin aber auf den Test gespannt, ob Samsung es generell sauber mit Daten umgeht.

 

[7hyrael]

Ist zwar ein Fall, der mit Consumerhardware nicht häufig vorkommen sollte, aber bei verteilten Transaktionen ist sowas schon wichtig. Wenn die eine Datenbank sich auf den Flush des Datenträgers verlässt und dann an die anderen meldet "ja ich habe es gespeichert" obwohl es gar nicht sicher persistiert ist und dann einen Stromausfall kriegt, ist der ganze Zustand nicht mehr korrekt.

Und in den Fall noch immer ein ziemlich vernachlässigbares Szenario, den wenn in so einer Umgebung keine usv vorhanden ist bzw. Nicht min. 1-2 weitere Replikationen bestehen, können sie Daten nicht so wichtig gewesen sein oder jener welcher das aufgesetzt hat sollte schon seit langem auf der Straße stehen.

 

[flaphoschi]

Das hat nichts mit Kondensatoren zu tun. Ein Flush muss ja bestätigt werden, egal ob es Kondensatoren gibt oder nicht. Das Verhalten ändert sich nicht durch Kondensatoren!

Nach der von Dir geposteten Spezifikation sollte "Flush" tatsächlich gleich greifen, Stützkondensatoren hin oder her.

Hinweis:
C "fflush()" != "NVM Express FLUSH"
Nicht das wird noch Verwirrung verursachen.