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

ob das wohl mit Absicht so gemacht wurde um die Lebensdauer künstlich zu erhöhen?

wahrscheinlich sollten die vorhandenen SSDs auch auf alle anderen Hintergrund/Sicherheitsfunktionen hin getestet werden...nicht dass noch mehr Funktionen(deren Arbeit die Lebensdauer verkürzen könnte) nicht ordnungsgemäss arbeiten
 
Mir ist es selten so schwer gefallen Informationen einzuordnen. Das bisschen was über Twitter geschrieben wird hat nämlich ziemliche Lücken um überhaupt beurteilen zu können wo die Ursache für die Beobachtung liegen könnte.

Es fängt damit an, dass sich komplett auf die SW des Host Systems verlassen wird. Richtigerweise würde man hier mit nen Protocol Analyzer direkt die einzelnen PCIe Pakete tracen und beurteilen, ob auf Seiten des Hosts alles korrekt abgelaufen ist. Hat natürlich nicht jedermann einfach mal zuhause :)

Desweiteren ist das eigentliche NVME Flush auch komplexer als man vielleicht denkt. Das Device gibt in der Identify Data Structure an ob ein Volatile Write Cache (VWC) vorhanden ist. Ist dies nicht der Fall - dann macht ein Flush genau gar nichts und Hostsysteme brauchen dann erst gar keinen Flush zu schicken. Desweiteren gibts nen Set Feature Command mit dem man verschiedene Parameter beeinflussen kann zur Laufzeit - auch den VWC - wobei das ganze optional ist und nicht mandatory. Alleine deshalb muss man schon auf NVME Ebene gucken was da wirklich passiert.

Zur eigentlichen Beobachtung:
FW von Consumer SSDs ist einfach schlecht was Powerfail Verhalten angeht. Daher sind industrial SSDs auch so teuer, selbst ohne spezifische Power Loss Protection Features. Da geht richtig viel Arbeit rein in die FW und Tests um all das auszubügeln wo die Controllerhersteller bei den Consumer FW keinen Grund mehr hatten.

Das Szenario welches der Twitter Autor nutzt ist eh nicht realistisch für einen normalen Desktop PC. Hier hat man entweder kompletten sudden powerloss (sei es durch Stromausfall oder hard reset) oder das System fährt geordnet runter. Nur die allerwenigsten werden ihre NVMe SSD im laufenden Betrieb aus dem Slot ziehen...

Alles in allem find ich es schweirig da irgendwas draus abzuleiten bei so wenig informationen wie der Autor liefert.
 
  • Gefällt mir
Reaktionen: TomH22, Hito360 und h00bi
Artikel-Update: Der Entwickler hat wie versprochen acht weitere SSDs auf die Problematik hin geprüft. Alle bestanden demnach den Test und behielten die Daten. Die Modelle wurden der obigen Tabelle hinzugefügt. Damit bleiben die SK Hynix Gold P31 und die Sabrent Rocket die einzigen Modelle mit Datenverlust, der beim erneuten Test wieder auftrat.

[Embed: Zum Betrachten bitte den Artikel aufrufen.]
 
  • Gefällt mir
Reaktionen: Piktogramm, schneeland, pvcf und 3 andere
Deswegen wenn es wichtig ist USV...
 
  • Gefällt mir
Reaktionen: Sebbi und karipa
Cool Master schrieb:
Deswegen wenn es wichtig ist USV...
einzig richtige Antwort. Getreu dem Motto: Vertrauen ist gut, Kontrolle ist besser. Im Enterprise Umfeld muss man einfach mit jeder Eventualität rechnen.
 
  • Gefällt mir
Reaktionen: Cool Master
I'm Enterprise Bereich würde aber auch niemand auf die Idee kommen Consumer SSDs zu nutzen.
 
  • Gefällt mir
Reaktionen: Weyoun
Nunja nur hilft eine USV in diesem Fall bei den betroffenen Festplatten eher wenig. Wenn ich das richtig verstehe meldet die SSD ein erfolgreiches Schreiben der Daten aus dem Cache obwohl es nicht der Fall ist.

Folgendes Szenario: Ich fahre das System runter, das OS sendet den flush Befehl, bekommt die Erfolgsmeldung von der SSD und schaltet das System aus -> eventueller Datenverlust.
Da bedarf es nicht unbedingt ein unerwartetes Ereignis wie ein Stromausfall um hier Daten zu verlieren.
 
  • Gefällt mir
Reaktionen: ElisaMüller, ottoman, Wowka_24 und 4 andere
Interessantes Thema.

Ich frage mich jetzt aber, wie relevant ist das ausserhalb der Enterprise IT wirklich?
Ein Stromausfall ist in der Regel ja unvorhersehbar. Ich hoffe das heutzutage niemand seinen Rechner "herunterfahrt" indem er einfach den Stecker zieht :D

Ein unerwarteter Stromausfall wird sicherlich nicht warten, ob Daten geflusht sind oder nicht. Wenn ein Stromausfall, der in dem Artikel beschriebenen Szenario bei "fake" geflushten Daten fuer Datenverlust sorgt, bei einer nicht betroffenen SSD ein kleines bisschen frueher passiert, sorgt er da genau so fuer Datenverlust.

Einziges was ich mir vorstellen koennte, wenn jemand eine der betroffenen SSDs als Wechselmedium verwendet. Dann ist ein solches Verhalten natuerlich extrem stoerend.

Die interessante Frage ist: Wielange dauert es nach dem "fake-flush" bis die Daten wirklich sicher sind? Sekundenbruchteile? Sekunden? Gar Minuten?
Letzteres kann ich mir nicht vorstellen, dann bestuende ja bei jedem regularen Shutdown die Gefahr des Datenverlustes.
 
Chuuei schrieb:
I'm Enterprise Bereich würde aber auch niemand auf die Idee kommen Consumer SSDs zu nutzen.

Backblaze denkt da wohl anders ;)
 
  • Gefällt mir
Reaktionen: Bigeagle
Chuuei schrieb:
I'm Enterprise Bereich würde aber auch niemand auf die Idee kommen Consumer SSDs zu nutzen.
Diverse kleinere Buden wie z.B. Google haben das bei Festplatten früher gemacht weil erheblich günstiger im Einsatz. Würde mich nicht wundern wenn bei weniger schreibintensiven Anwendungsfällen auch Consumer SSDs eingesetzt werden, ausfallen kann beides und am Ende vom Tag ist es eine Kosten/Nutzenrechnung was rentabler ist.
 
  • Gefällt mir
Reaktionen: Kontergewicht
@ Wer Datenverlust vermeiden will, habe USV zu haben

Mein Umspannunsgwerk hat Vanadium-Batterien, um das Netz stabil zu halten. Sehr selten reicht das nicht und Software darf gern wissen müssen, was im Falle eines Falles passiert ist. Dafür wurde beispielsweise mal Journaling erfunden - es ist kein absolutes Failsafe vor Datenverlust bei Stromausfall, schon gar nicht, wenn DRAM-Cache vom Dateisystem benutzt wird (machen heute alle), aber es sorgt dafür, dass die Software, sofern sie will, weiß, welche Dateien eventuell kaputt sind und welche nicht. Darum gehts! Welche Daten muss ich aus einem Backup oder aus einer ShadowCopy oder einem früheren Wiederherstellungspunkt oder einem Snapshot wiederherstellen und welche nicht. Das kostet im Falle des Falles Zeit - und die USV würde einen vor diesem Zeitinverlust bewahren - aber weil es nur sehr selten ist, kann ich damit leben, dass es mich Zeit kostet; solange, wie gesagt, die Software weiß, welche Dateien kaputt sein könnten und welche sicher ganz sind. Wenn die Firmware der SSD aber das Dateisystem anlügt, dann muss das Dateisystem und die "Systemaktualisierungeninstallationsroutine" denken, dass diese nicht beschädigt seien, obwohl sie es ggf. doch sind und das ist einfach ein absolutes Unding das durch "installier gefälligst ein USV, damit dein Arbeistplatz insgemsamt mehr Strom verbraucht" nicht zu beheben ist.

In Fedora Linux ist es beispielsweise grundsätzlich so, dass, solange die Firmware nicht lügt, der Rechner im Systemaktualisierungsprozess hart ausgeschaltet werden oder abstürzen oder stromwegabschmieren kann und hinterher dauert das Starten zwar sehr lange, aber man wird begrüßt mit der Meldung, dass XY Updates nicht installiert werden konnten und fertig. Das funktioniert sogar so gut, dass ein instabil laufender Rechner, bei dem ein Bit auch mal auf dem Weg irgendwo zwischen CPU und RAM flipt (wovor ECC-RAM nicht schützt), nicht dazu führt, dass kaputte Systemdateien als erfolgreich installiert gelten könnten. Das System setzt sich, weil die Software doch tatsächlich intelligent geschrieben wurde, in den Zustand vor dem Abschmieren zurück. Das funktioniert aber nur solange die Software weiß, welche Dateien sicher geschrieben wurden und bei welchen das nicht sicher ist.
 
Dann kann ich ja beruhigt meine P5 Plus einbauen.

Habe nämlich gestern meine bekommen und keine 5 Minuten bevor ich den Artikel gelesen hatte das Siegel von der Verpackung geöffnet. :cool_alt:
 
  • Gefällt mir
Reaktionen: Mertsch
die beiden bisher betroffenen SSD benutzen vielleicht einen älteren Phison Controller mit einem Fehler in der Firmware. Neuere Phison wie bei der Firecuda sind wohl nicht davon betroffen.
 
Chuuei schrieb:
Zur eigentlichen Beobachtung:
FW von Consumer SSDs ist einfach schlecht was Powerfail Verhalten angeht. Daher sind industrial SSDs auch so teuer, selbst ohne spezifische Power Loss Protection Features. Da geht richtig viel Arbeit rein in die FW und Tests um all das auszubügeln wo die Controllerhersteller bei den Consumer FW keinen Grund mehr hatten.

Wenn das Storage flush oder sync korrekt implementiert spielt Power Loss Protection quasi keine Rolle mehr.
Ergänzung ()

MountWalker schrieb:
Dafür wurde beispielsweise mal Journaling erfunden
Journaling braucht korrekt implementiertes flush oder sync
Ergänzung ()

ManInTheMiddle schrieb:
Vielleicht kommen ja doch wieder RAID Controller mit Akku in Mode ;-)

Der Akku plus RAM ist ein SPOF
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: ElisaMüller und Piktogramm
ManInTheMiddle schrieb:
Vielleicht kommen ja doch wieder RAID Controller mit Akku in Mode ;-)
Oh Gott nein! Was diese Controller teils für eigenartige Verhalten haben und die Raid samt der darauf gespeicherten Daten durch ihre proprietären Techniken quasi verdongeln.
Ganz abgesehen davon, dass diese Controller genauso darauf ausgelegt sind, dass angeschlossene Laufwerke sich an die Spezifikation halten!

Chuuei schrieb:
I'm Enterprise Bereich würde aber auch niemand auf die Idee kommen Consumer SSDs zu nutzen.
Stimmt so pauschal nicht. Wenn eine Firma sich SAP, Oracle, Microsoft und Ähnliches ans Bein bindet und jede zusätzliche Lizenz unglaublich teuer ist, dann lohnt es EnterpriseHW zu kaufen um die Ausfallquote unter Kontrolle zu halten. Bei Firmen die einen günstigeren Softwarestack nutzen oder gar überwiegend selbst unter Kontrolle haben ist es oft günstiger mehr Redundanzen mit 0815 Hardware aufzubauen.
 
Zuletzt bearbeitet:
foofoobar schrieb:
[...]
Journaling braucht korrekt implementiertes flush oder sync
[...]
Sehr richtig und genau dieser Punkt ist ja eigentlich der Punkt meines Beitrags. ;)
 
  • Gefällt mir
Reaktionen: Piktogramm
Chuuei schrieb:
Es fängt damit an, dass sich komplett auf die SW des Host Systems verlassen wird. Richtigerweise würde man hier mit nen Protocol Analyzer direkt die einzelnen PCIe Pakete tracen und beurteilen, ob auf Seiten des Hosts alles korrekt abgelaufen ist. Hat natürlich nicht jedermann einfach mal zuhause :)
Das ist ne ganze Ecke zu paranoid. Wenn Software (das Betriebssystem) ein NVMe Flush auslöst kann man schon davon ausgehen, dass das auch so über den Bus geht, vor allem wenn das Verhalten der SSD im erwartetem Rahmen liegt (Verringerung der möglichen IOPs). Wäre dem nicht so, würde die CPU, deren Firmware oder irgend ein PCIe Controller dazwischen sehr weit außerhalb der Spec laufen. Wäre dem so, würde das an sehr vielen Stellen deutlicher auffallen.

Ganz abgesehen, LogicAnalyzer die PCIe 4 oder gar 5 schaffen sind abartig teuer, selbst wenn man den Kram nur mieten würde.


Desweiteren ist das eigentliche NVME Flush auch komplexer als man vielleicht denkt. Das Device gibt in der Identify Data Structure an ob ein Volatile Write Cache (VWC) vorhanden ist. Ist dies nicht der Fall - dann macht ein Flush genau gar nichts und Hostsysteme brauchen dann erst gar keinen Flush zu schicken.

Desweiteren gibts nen Set Feature Command mit dem man verschiedene Parameter beeinflussen kann zur Laufzeit - auch den VWC - wobei das ganze optional ist und nicht mandatory. Alleine deshalb muss man schon auf NVME Ebene gucken was da wirklich passiert.
Und der Flush Command ist einer der simpelsten:
7.1. Flush Command
[...]
If a volatile write cache is not present or not enabled, then Flush commands shall have no effect and:
a) shall complete successfully if a sanitize operation is not in progress; and
b) may complete successfully if a sanitize operation is in progress.
All command specific fields are reserved.
Im Gegensatz zu deiner Beschreibung ("Flush [macht] genau gar nichts") muss Flush immer verarbeitet werden um die NVMe Spec einzuhalten. Entsprechend muss Software das Verhalten nicht anpassen!
Flushes sind wichtig, da fängt man nicht an das unnötig kompliziert zu machen!

Das Szenario welches der Twitter Autor nutzt ist eh nicht realistisch für einen normalen Desktop PC. Hier hat man entweder kompletten sudden powerloss (sei es durch Stromausfall oder hard reset) oder das System fährt geordnet runter. Nur die allerwenigsten werden ihre NVMe SSD im laufenden Betrieb aus dem Slot ziehen...
Ich entwerfe meine Tests ja meist so, dass sie möglichst Fehler provozieren und nicht nach "wird im Alltag schon gut gehen". So wurde das der Test auch ausgelegt, ein falsch bestätigter Flush fällt reproduzierbar auf, wenn man die Energie weg nimmt.

Alles in allem find ich es schweirig da irgendwas draus abzuleiten bei so wenig informationen wie der Autor liefert.
Die Information war hauptsächlich: Es gibt NVMe Laufwerke, die außerhalb der Spezifikation laufen.
 
  • Gefällt mir
Reaktionen: pvcf
Piktogramm schrieb:
Wenn Software (das Betriebssystem) ein NVMe Flush auslöst kann man schon davon ausgehen, dass das auch so über den Bus geht ...

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.

Mein Beitrag ging nicht darum die eigentliche Beobachtung in Frage zu stellen. Nur bei der Ursache legt sich der Autor auf etwas fest was er in keiner Weise auf technischer Ebene überprüfen kann und schließt bestimmte Teile die Probleme verursachen könnten einfach aus (hier Software).

Piktogramm schrieb:
Im Gegensatz zu deiner Beschreibung ("Flush [macht] genau gar nichts") muss Flush immer verarbeitet werden um die NVMe Spec einzuhalten.
Moment, das sind zwei verschiedene Dinge. Ich habe nicht geschrieben das Flush nicht durch den Controller verarbeitet wird. Ich habe gesagt das das Flush nichts macht. Genau das hast du Zeilen vorher auch genau so zitiert:
If a volatile write cache is not present or not enabled, then Flush commands shall have no effect
 
Zurück
Oben