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
Aufmerksamkeit erregen sollte das Thema, dass sich jeder Nutzer davon emotional tangieren lässt sollte aber nicht das Ziel sein. Stromausfälle sind bei NVMe-SSD Nutzern nicht die Regel, bzw. ein teures Setup gehört mit entsprechendem Stromspeicher geschützt.
Und da es nicht Herstellerspezifisch zu sein scheint, wird eher ein OEMFirmwareproblem sein.
Ich als Privatnutzer würde aber so ein Firmware-Update nicht zwingend auf meine SSD klatschen - die "Gefahrensituation" tritt mir zu selten auf.
ABER wenn ich Stromausfallprobleme habe mache ich erst recht keine Firmware- oder BIOSupdates in der Wohnung
Wenn man einen sync ausführt lehrt das Betriebssystem die Caches, ab jetzt gilt es - nur - für die Software als geschrieben. Was die Hardware wirklich tut ist ein Implementierungsdetail! Es kann sein, dass die Hardware eigene transparente flüchtige Caches hat (wie hier beschrieben und üblich). Wenn diese um Einsatz kommen, muss die Hardware selbst sicherstellen dass die Daten persistiert (Hinweis -> Kondensatoren) werden. Egal ob das System jetzt abstürzt, Neustartet, der Strom ausfällt oder die Batterie leer ist.
So kann man den Dingern nichts vertrauen, nicht mal nach dem Herunterfahren wäre man sicher. Klassiker in der Entwicklung ist ein bewusste Sync um anschließen einen Absturz herbeizuführen um diesen zu analysieren, blöd wenn dabei Datenverlust auftritt. Da wäre ich mal richtig sauer.
Hinweis:
fflush() // flush der Daten zum Kernel
fsync() (blockiert) und sync() (nicht blockierend) // Übergabe der Daten vom Kernel an die Hardware
Was die Hardware wirklich tut steht in den Spezifikationen der Hardware. Das eigentliche Schreiben kann später passieren. Wenn in den Spezifikationen steht, dass man noch mindestens 30 Sekunden lang die Stromversorgung aufrecht erhalten muss. Okay. Wenn da steht, dass die Hardware die Daten schreiben wird die sie erhalten hat, was auch immer passiert. Okay. Letzteres ist sicher das, was wir von kritischen System erwarten. Dazu zähle ich meinen Laptop und auch ein GPS-Gerät
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!
@Chesterfield
Backups helfen an der Stelle gar nicht.
M1ch1 schrieb:
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
Im Zweifelsfall bei Aktionen wie "Laufwerk wird beschrieben und nach Akion wird Laufwerk ausgeworfen" Wenn ein Laufwerk meldet, dass es Daten geschrieben hat, während die Daten noch im Cache sind, ist der Aufwurf einfach katastrophal.
Wenn es ein Kernelpanic gibt, wird eigentlich auch ein Flush von allen Laufwerken verlangt. Mitunter schlicht um so viel vom Arbeitsstand zu retten wie möglich und zum Anderen um Logfiles zu schreiben. Wenn das nicht zuverlässig klappt ist das auch Mist. Bei Stromausfällen genauso, oder schlicht wenn der Akku leer ist und das System ein "Flush" veranlässt, wenn das PowerOK-Signal auf 0 fällt.
Wattwanderer schrieb:
Sicherlich nicht schön aber wie oft ist denn bei euch der Strom ausgefallen?
2020?
16h Stromausfall in Summe, und ich habe glaube mehr als 10mal die Uhr von Küchengeräten stellen müssen.
Rickmer schrieb:
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.
Es ist kein Cheat, wenn es so seit >20Jahren so seitens Apple dokumentiert wird. Wenn mal etwas sucht stellt man auch fest, dass dieses Verhalten und vor allem die Abweichung zu Linux bekannten Softwareprojekten immer wieder auffällt (Go, Python haben dazu Issues im Bugtracker).
Schlimmer ist bei Apple, dass selbst wenn man den "richtigen" Befehl nutzt, dass die SSDs unsäglich lange brauchen um Daten zu schreiben.
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 waren allerdings alles lokale Ausfälle der einzelnen Lasten am Netz und nicht am Netz.
Das sagt viel eher etwas über die Infrastruktur der Kommunen aus.
Wir (Amprion) haben etwa 10 mal häufiger mit Problemen der Kommunalen Anbinder zu tun, als mit gewerblichen Kunden. Da erkennt man schon ein Muster. Bei Kommunen gehen alte Umspannwerke und Leitungen gerne mal aus Altersgründen außer Betrieb und ein Neubau wird kaputt protestiert oder die Planung dauert 10 Jahre länger als geplant.
Die Netzstabilität an sich ist in der Tat in den letzten 10-20 Jahren deutlich besser geworden (Abweichung von Normfrequenz).
Das hatte primär einfach mit der Digitalisierung zu tun. Ein Rechenzenter kann potentiell das komplette Netz als Ganzes mit Digitalreglern unter Kontrolle halten. Das waren/sind mal hunderttausende einzelne Analogregelysteme.
Deutschland kann den kompletten Stromverbrauch durch die vorhandenen fossilen Kapazitäten decken.
Das ist dabei nicht das Hauptproblem.
Sieht nach ziemlichen Pfusch bei der Implementierung aus. Für Privatanwender in der Regel jetzt keine große Gefahr, da höchst unwahrscheinlich. Aber die Produkte arbeiten nicht wie beworben. Daran gibt es nichts zu leugnen.
Interessant wäre zu wissen, wie lange es dann am Ende wirklich dauert, bis alle Daten im nichtflüchtigen Speicher sind.
Ich habe manchmal ein ähnliches Problem mit meiner tragbaren Samgung T5 500GB SATA-SSD.
Wenn ich Dateien darauf kopieren und die SSD in Windows ordnungsgemäß auswerfe, dann kann es passieren dass diese Daten dann auf den anderen PC kaputt sind.
Die sind dann in einem Ordner namans found001, wenn ich die SSD dann von Windows reparieren lasse.
Zugreifen kann ich auf diese Dateien nicht.
Klar könnte es, nur sind manche Dateisysteme dagegen besser gehärtet. Bei ZFS z.B. sind einige Maßnahmen enthalten welche der nicht vertrauenswürdigen Consumer HW entgegenwirken sollen. Manche Dinge davon sind für Features unabhängig davon sogar erforderlich, ohne Copy on Write müssten Snapshots anders umgesetzt werden, etc.
Ändert nichts daran dass die hier bemängelten SSDs ein Update mit korrektem Verhalten benötigten, jedoch gibt es Dateisysteme die davon schwerer als andere getroffen werden.
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.
Man kann Stromausfallsichere Datensystem bauen, die immer gültige Daten haben, auch wenn der Strom zu einem beliebigen Zeitpunkt ausfällt. Wichtig ist dabei nur, dass man von der Hardware erfährt, wann ein Schreibvorgang wirklich abgeschlossen ist. Dadurch kann man z.B. einfach Dinge machen wie:
temporäre Kopie einer Datei erstellen
temporäre Kopie inhaltlich ändern
temporäre Kopie auf Flash syncen (hier muss man warten bis der Flash Speicher fertig ist)
alte Datei löschen und durch temporäre ersetzen (Hierbei wird der Namen geändert, nicht der Inhalt. Genaugenommen editiert man den Ordner in dem die Datei liegt)
Durch den sync aufs flash kann man die Fehlerfälle auf ein paar behandelbare eingrenzen:
Es ist keine temporäre Datei vorhanden: alles ist gut
Es ist eine temporäre Datei vorhanden: der Schreibvorgang wurde vielleicht unterbrochen, temporäre Datei löschen und alten Stand benutzen
Die temporäre Datei ist vorhanden aber nicht die Orginale: beim umbenennen ist der Strom ausgefallen, temporäre Datei hat jedoch dank sync gültige Daten und kann weiter verwendet werden.
Wenn du nicht weißt, ob die Hardware den Schreibvorgang tatsächlich sicher abgeschlossen hat, dann löschst du deine Originaldaten bevor die Kopie fertig geschrieben wurde. Beim Stromausfall hast du dann eine kaputte Datei oder gar keine Daten. Aufs Dateisystem bezogen kann es dir sogar das ganze Dateisystem schrotten.
Quelle: Ich entwickle Hausgeräte, bei denen es normal ist das die Nutzer einfach den Stecker ziehen.
@Chesterfield
Hoppala, mein Fehler.
Wobei allein eine USV auch nicht alle Probleme löst. Wenn die USV nicht mehr kann und mit einem Cut-Off droht muss Flush zuverlässig funktionieren, bei Kernelpanics auch.
@I'm unknown
Dateisysteme können an der Stelle gar nichts kompensieren, wenn nicht absolut gesichert ist, dass Daten wirklich auch auf dem Festspeicher gelandet sind.
Da reicht eventuell auch ein Absturz, Freeze, versehentlicher Reset oder Powerstecker ziehen aus.
Das wäre dann schon häufiger auch im Consumer-Bereich der Fall.
Das Problem im Artikel müsste doch umgehbar sein,
falls man eine SSD ohne DRAM-Cache kauft
und zusätzlich im Windows oder anderem OS den Schreibcache deaktiviert.
Oder?
Das Problem im Artikel müsste doch umgehbar sein,
falls man eine SSD ohne DRAM-Cache kauft
und zusätzlich im Windows oder anderem OS den Schreibcache deaktiviert.
Das hindert eine fehlerhafte Firmware trotzdem nicht daran, schon frühzeitig ein Flush zurückzumelden, während die NAND-Zellen noch am arbeiten sind. Macht es zwar schwieriger oder hoffentlich weniger wahrscheinlich (weniger Caches verringern vielleicht die Komplexität der Firmware und damit die Fehlerwahrscheinlichkeit), aber ausschließen würde ich es nicht
@Flare
Der Schreibcache vom Betriebssystem sollte damit ersteinmal nichts zu tun haben. Programme die ihre Daten sicher auf der Platte schreiben wollen nutzen einfach selbst fsync()[1] und weisen so an, dass keinerlei Caches genutzt werden sollen.
Bei SSDs ohne Dram wird es komplizierter. Da gibt es ja einige Modelle die HMB unterstützen und so den Arbeitsspeicher als Cache nutzen. Da wäre tendenziell auch möglich, dass Laufwerke Flushes bestätigen, obwohl die Daten noch im flüchtigem Speicher liegen. Das müsste man sich von Model zu Model anschauen wenn man sicher sein will.
[1] Oder was auch immer das Betriebssystem als Analog anbietet.
Da reicht eventuell auch ein Absturz, Freeze, versehentlicher Reset oder Powerstecker ziehen aus.
Das wäre dann schon häufiger auch im Consumer-Bereich der Fall.
Hier ging es um stromlos machen. Beim Absturz, Freeze, Reset und Powertaste festhalten fallen also raus. Bliebe Powerstecker aber die Netzteile haben zum Teil erstaunlich lange Stützzeit. Licht flackert, Wecker blinkt mit falscher Zeit aber die Rechner liefen oft genug einfach durch.
Für mich klingt das wie eine Sensationsmeldung. Das Auto wird gefährlich wenn man auf der Autobahn mit 470 km/h unterwegs ist.
Möchte wissen wer so schlampig arbeitet, um eine SSD mit einem Schlag stromlos werden zu lassen und dass ein nicht geleerter Cache zum Problem wird.
Daher wäre es schön gewesen wenn hier noch erklärt worden wäre wann und wie relevant die Untersuchung ist.
Wäre es ein wirkliches Problem, dann hätten wir bei den Mrd (?) ausgelieferten SSDs so manche Horrormeldungen gehört.
Zumal das ein Problem ist mit dem Filesystementwickler lange gekämpft und eine Antwort gefunden haben mit Journaled Filesystem. Erinnere mich mich an die ersten kindliche Freude als man mit "fiesen Druck auf Resettaste" herumspielte als die ersten Journaled Filesysteme robust genug wurden. Und ja NTFS hat ein Journal, ebenso die meisten Linux FSs außer bei denen wo man explizit darauf verzichtet wie etwa vfat, exfat, ext2 ...
