Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsSSD-Cache-Problem: Trotz Flush droht Datenverlust bei Stromausfall
Auf Basis eigener Versuche berichtet der Entwickler Russ Bishop, dass es bei einigen NVMe-SSDs trotz angeblich erfolgter Pufferspeicher-Leerung (Cache Flush) zu Datenverlusten kommen kann. Bei zwei von vier getesteten NVMe-SSDs verschiedener Hersteller sei dies aufgetreten. Bishop will weitere prüfen.
Könnte daran liegen, dass bei NVMe-SSDs eine parallele Abarbeitung der Befehle erfolgt.
Vielleicht könnte man den Flush-Befehl dann irgendwie anders umsetzen, dass dies nicht passiert.
Bei WD (Sandisk) und Samsung scheint's ja (zumindest bei den beiden Modellen) zu funktionieren.
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)
Ich verstehe das Problem nicht ganz.
Bzw das Problem schon, aber die Auswirkungen sollten ja vernachlässigbar sein.
Die SSD verliert Daten die als gesichert geflaggt sind, wenn die Spannung weg ist.
Nur warum ist das erst ein Problem, wenn die "gesichert" flag gesetzt wird? Die Information "Daten wurden gespeichert" kann ja auch nicht gespeichert werden fürs nächste Mal, also muss das Programm theoretisch immer von Datenverlust ausgehen
Also verstehe ich jetzt die praktische Bedeutung nicht ganz.
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.
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.
War das Thema nicht angefangen dadurch, das aufgefallen ist, dass Macbooks bis zu 5 Minuten nach dem Write noch Daten verlieren können wenn ein plötzlicher Shutdown kommt?
Bei LTT wurde am Freitag in der WAN Show etwas der Art diskutiert.
Das Problem ist, dass die ssd meldet, dass die Daten gespeichert sind, obwohl sie noch nicht gespeichert sind.
Auch wenn man jetzt beim heimanwender hier nicht unbedingt von Datenverlust ausgehen sollte, ist das trotzdem zumindest ziemlicher Pfusch. Wenn die ssd meldet, dass Daten gespeichert wurden, dann müssen die auch komplett geschrieben und "permanent" sein und nicht noch irgendwo zwischen Cache und nand rumfahren.
das erinnert mich irgendwie an die geschichte mit den xerox druckern vor... über 15 Jahren?
ich finde es aber von ihm nicht sonderlich hilfreich es nicht vorher bei den betroffenen herstellern angesprochen zu haben... er lässt sie hier ins offene messer laufen
Da wollen sich wohl einige Hersteller einen Geschwindigkeits- oder Laufzeitvorteil erschleichen, der nicht realistisch ist.. oder wie soll man diesen "Fehler" (bzw "Trick") verstehen?
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.
Vor allem ist dann fraglich, ob Write Barriers allgemein mit der jeweiligen NVMe richtig funktionieren. Ansonsten kann man sich auf Datenbanken (und Dateisysteme...) darauf einfach nicht verlassen.
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.
Gut, dass sich jemand diesem Thema nocheinmal praktisch annimmt. Ich bin sehr gespannt auf die Ergbnisse.
In Tests vor Jahren gab es ja schon ganz ähnliche Ergebnisse bis hin zum Totalschaden an SSDs:
" Our experimental results with 17 SSDs from six different vendors show that most of the SSDs we tested did not adhere strictly to the expected semantics of behavior under power faults. We have observed five out of the seven expected failure types, including bit corruption, shorn writes, unserializable writes, metadata corruption, and dead device.
" Reliability Analysis of SSDs Under Power Fault (2016_TOCS_SSD.pdf)
Könnte daran liegen, dass bei NVMe-SSDs eine parallele Abarbeitung der Befehle erfolgt.
Vielleicht könnte man den Flush-Befehl dann irgendwie anders umsetzen, dass dies nicht passiert.
Könnte daran liegen, dass bei NVMe-SSDs eine parallele Abarbeitung der Befehle erfolgt.
Vielleicht könnte man den Flush-Befehl dann irgendwie anders umsetzen, dass dies nicht passiert.
Bei WD (Sandisk) und Samsung scheint's ja (zumindest bei den beiden Modellen) zu funktionieren.
Punkt 7.1.
Kommt ein Flush, muss auf den nicht flüchtigen Speicher geschrieben und nach Abschluss bestätigt werden. Kommt die Bestätigung bevor die Daten geschrieben werden, ist die NVMe Spezifikation verletzt. Mit Parallelität hat das nichts zu tun!
