it-swarm.com.de

Werden Dateibearbeitungen unter Linux direkt auf der Festplatte gespeichert?

Früher dachte ich, dass Dateiänderungen direkt auf der Festplatte gespeichert werden, dh sobald ich die Datei schließe und mich entscheide, auf Speichern zu klicken/auszuwählen. In einem kürzlich geführten Gespräch sagte mir jedoch ein Freund, dass dies normalerweise nicht der Fall ist. Das Betriebssystem (speziell wir haben über Linux-Systeme gesprochen) behält die Änderungen im Speicher bei und verfügt über einen Daemon, der den Inhalt tatsächlich aus dem Speicher auf die Festplatte schreibt.

Er gab sogar das Beispiel externer Flash-Laufwerke an: Diese werden in das System eingebunden (in den Speicher kopiert), und manchmal kommt es zu Datenverlust, weil der Dämon den Inhalt noch nicht im Flash-Speicher gespeichert hat. Aus diesem Grund entfernen wir Flash-Laufwerke.

Ich habe keine Kenntnisse über die Funktionsweise von Betriebssystemen und daher absolut keine Ahnung, ob und unter welchen Umständen dies zutrifft. Meine Hauptfrage lautet: Geschieht dies wie in Linux/Unix-Systemen (und möglicherweise anderen Betriebssystemen) beschrieben? Bedeutet dies beispielsweise, dass meine Änderungen höchstwahrscheinlich verloren gehen, wenn ich den Computer sofort nach dem Bearbeiten und Speichern einer Datei ausschalte? Vielleicht hängt es vom Festplattentyp ab - herkömmliche Festplatten im Vergleich zu Solid-State-Festplatten?

Die Frage bezieht sich speziell auf Dateisysteme, die eine Festplatte zum Speichern der Informationen haben, obwohl jede Klarstellung oder jeder Vergleich gut aufgenommen wird.

58
JuanRocamonde

wenn ich den Computer sofort nach dem Bearbeiten und Speichern einer Datei ausschalte, gehen meine Änderungen höchstwahrscheinlich verloren.

Sie könnten sein. Ich würde nicht "höchstwahrscheinlich" sagen, aber die Wahrscheinlichkeit hängt von vielen Dingen ab.


Eine einfache Möglichkeit, die Leistung von Dateischreibvorgängen zu steigern, besteht darin, dass das Betriebssystem nur die Daten zwischenspeichert, die Anwendung, die der Schreibvorgang durchlaufen hat, mitteilt (belügt) und später tatsächlich schreibt. Dies ist besonders nützlich, wenn gleichzeitig andere Festplattenaktivitäten ausgeführt werden: Das Betriebssystem kann Lesevorgänge priorisieren und die Schreibvorgänge später ausführen. Es kann auch die Notwendigkeit eines tatsächlichen Schreibvorgangs vollständig beseitigen, z. B. in dem Fall, in dem eine temporäre Datei schnell danach entfernt wird.

Das Caching-Problem ist stärker ausgeprägt, wenn der Speicher langsam ist. Das Kopieren von Dateien von einer schnellen SSD auf einen langsamen USB-Stick erfordert wahrscheinlich viel Schreib-Caching, da der USB-Stick einfach nicht mithalten kann. Ihr Befehl cp kehrt jedoch schneller zurück, sodass Sie weiterarbeiten und möglicherweise sogar die gerade kopierten Dateien bearbeiten können.


Ein solches Caching hat natürlich den Nachteil, dass einige Daten verloren gehen können, bevor sie tatsächlich gespeichert werden. Der Benutzer wird verärgert sein, wenn sein Editor ihm mitteilt, dass der Schreibvorgang erfolgreich war, die Datei sich jedoch nicht auf der Festplatte befand. Aus diesem Grund gibt es den Systemaufruf fsync() , der erst zurückgegeben werden soll, nachdem die Datei tatsächlich auf die Festplatte gelangt ist. Ihr Editor kann dies verwenden, um sicherzustellen, dass die Daten in Ordnung sind, bevor er dem Benutzer meldet, dass der Schreibvorgang erfolgreich war.

Ich sagte, "soll", da das Laufwerk selbst dem Betriebssystem die gleichen Lügen erzählen und sagen könnte, dass der Schreibvorgang abgeschlossen ist, während die Datei wirklich nur in einem flüchtigen Schreibcache innerhalb des Laufwerks existiert. Je nach Laufwerk führt kein Weg daran vorbei.

Zusätzlich zu fsync() gibt es auch die Systemaufrufe sync() und syncfs(), die das System auffordern, sicherzustellen, dass alle systemweiten Schreibvorgänge oder alle Schreibvorgänge auf einem bestimmten System ausgeführt werden Dateisystem haben die Festplatte getroffen. Mit dem Dienstprogramm sync können diese aufgerufen werden.

Dann gibt es noch das O_DIRECT - Flag für open() , das "versuchen soll, die Cache-Effekte der E/A zu und von dieser Datei zu minimieren". Durch das Entfernen des Cachings wird die Leistung verringert. Dies wird daher hauptsächlich von Anwendungen (Datenbanken) verwendet, die ihr eigenes Caching durchführen und die Kontrolle darüber behalten möchten. (O_DIRECT Ist nicht ohne Probleme, die Kommentare auf der Manpage sind etwas amüsant.)


Was beim Ausschalten passiert, hängt auch vom Dateisystem ab. Es sind nicht nur die Dateidaten, um die Sie sich Sorgen machen sollten, sondern auch die Metadaten des Dateisystems. Die Dateidaten auf der Festplatte zu haben, nützt nicht viel, wenn Sie sie nicht finden können. Nur um eine Datei auf eine größere Größe zu erweitern, müssen neue Datenblöcke zugewiesen und irgendwo markiert werden.

Wie ein Dateisystem mit Metadatenänderungen umgeht und die Reihenfolge zwischen Metadaten und Datenschreibvorgängen sehr unterschiedlich ist. Wenn Sie beispielsweise mit ext4 Das Mount-Flag data=journal Setzen, durchlaufen alle Schreibvorgänge - auch Datenschreibvorgänge - das Journal und sollten ziemlich sicher sein. Das bedeutet auch, dass sie zweimal geschrieben werden, sodass die Leistung sinkt. Die Standardoptionen versuchen, die Schreibvorgänge so anzuordnen, dass sich die Daten auf der Festplatte befinden, bevor die Metadaten aktualisiert werden. Andere Optionen oder ein anderes Dateisystem können besser oder schlechter sein. Ich werde nicht einmal eine umfassende Studie versuchen.


In der Praxis sollte die Datei auf einem leicht geladenen System innerhalb weniger Sekunden auf der Festplatte erscheinen. Wenn Sie mit Wechseldatenträgern arbeiten, müssen Sie das Dateisystem aushängen, bevor Sie das Medium abrufen, um sicherzustellen, dass die Daten tatsächlich an das Laufwerk gesendet werden und keine weiteren Aktivitäten stattfinden. (Oder lassen Sie Ihre GUI-Umgebung das für Sie tun.)

70
ilkkachu

Es gibt eine extrem einfache Methode, um zu beweisen, dass nicht wahr sein kann, dass Dateibearbeitungen immer direkt auf der Festplatte gespeichert werden, nämlich die Tatsache, dass es Dateisysteme gibt, die = werden überhaupt nicht von einer Festplatte gesichert. Wenn ein Dateisystem überhaupt keine Festplatte hat, dann kann es unmöglich die Änderungen auf die Festplatte schreiben, je.

Einige Beispiele sind:

  • tmpfs, ein Dateisystem, das nur in RAM (oder genauer gesagt im Puffercache) vorhanden ist)
  • ramfs, ein Dateisystem, das nur im RAM vorhanden ist
  • any Netzwerkdateisystem (NFS, CIFS/SMB, AFS, AFP,…)
  • any virtuelles Dateisystem (sysfs, procfs, devfs, shmfs,…)

Aber selbst für festplattengestützte Dateisysteme ist dies normalerweise nicht der Fall. Die Seite So beschädigen Sie eine SQLite-Datenbank enthält ein Kapitel mit dem Namen Fehler beim Synchronisieren , das viele verschiedene Arten des Schreibens beschreibt (in In diesem Fall können Commits in eine SQLite-Datenbank nicht auf der Festplatte eintreffen. In SQLite gibt es auch ein Whitepaper, in dem die vielen Rahmen erläutert werden, durch die Sie springen müssen, um Atomic Commit In SQLite zu gewährleisten. (Beachten Sie, dass Atomic Write ein viel schwierigeres Problem ist als nur Write, aber natürlich ist das Schreiben auf die Festplatte ein Unterproblem des atomaren Schreibens, und Sie können es In diesem Artikel erfahren Sie auch viel über dieses Problem.) Dieser Artikel enthält einen Abschnitt über Dinge, die schief gehen können , der einen Unterabschnitt über Unvollständige Festplattenspülungen , die einige Beispiele für subtile Komplikationen enthalten, die verhindern können, dass ein Schreibvorgang die Festplatte erreicht (z. B. der Festplattencontroller, der meldet, dass er auf die Festplatte geschrieben hat, obwohl er dies nicht getan hat). t - ja, es gibt Festplattenhersteller, die dies tun, und es könnte sogar gemäß der ATA-Spezifikation legal sein, da diesbezüglich nicht eindeutig formuliert ist.

14
Jörg W Mittag

Es stimmt, dass die meisten Betriebssysteme, einschließlich Unix, Linux und Windows, einen Schreibcache verwenden, um den Betrieb zu beschleunigen. Das bedeutet, dass das Ausschalten eines Computers ohne Herunterfahren eine schlechte Idee ist und zu Datenverlust führen kann. Gleiches gilt, wenn Sie einen USB-Speicher entfernen, bevor er entfernt werden kann.

Die meisten Systeme bieten auch die Möglichkeit, Schreibvorgänge synchron zu machen. Das bedeutet, dass sich die Daten auf der Festplatte befinden, bevor eine Anwendung eine Erfolgsbestätigung erhält, auf Kosten der Langsamkeit.

Kurz gesagt, es gibt einen Grund, warum Sie Ihren Computer ordnungsgemäß herunterfahren und den USB-Speicher ordnungsgemäß zum Entfernen vorbereiten sollten.

11
RalfFriedl

1. Flash-basierter Speicher

Hängt es vom Festplattentyp (herkömmliche Festplatten im Vergleich zu Solid-State-Festplatten) oder einer anderen Variablen ab, die mir möglicherweise nicht bekannt ist? Kommt es (wenn ja) nur unter Linux vor oder ist dies in anderen Betriebssystemen vorhanden?

Wenn Sie die Wahl haben, sollten Sie nicht zulassen, dass Flash-basierter Speicher ohne ein sauberes Herunterfahren Strom verliert.

Bei kostengünstigem Speicher wie SD-Karten können Sie damit rechnen, dass ganze Löschblöcke (um ein Vielfaches größer als 4 KB) verloren gehen und Daten verloren gehen, die zu verschiedenen Dateien oder wesentlichen Strukturen des Dateisystems gehören können.

Einige teure SSDs behaupten möglicherweise, angesichts eines Stromausfalls bessere Garantien zu bieten. Tests von Drittanbietern deuten jedoch darauf hin, dass viele teure SSDs dies nicht tun. Die Ebene, die Blöcke für die "Verschleißnivellierung" neu zuordnet, ist komplex und proprietär. Mögliche Fehler sind der Verlust aller Daten auf dem Laufwerk.

Unter Anwendung unseres Test-Frameworks testen wir 17 Standard-SSDs von sechs verschiedenen Anbietern mit insgesamt mehr als dreitausend Fehlerinjektionszyklen. Unsere experimentellen Ergebnisse zeigen, dass 14 der 17 getesteten SSD-Geräte ein überraschendes Fehlerverhalten bei Stromausfällen aufweisen, einschließlich Bitbeschädigung, geschorenen Schreibvorgängen, unserialisierbaren Schreibvorgängen, Beschädigung von Metadaten und vollständigem Geräteausfall.

2017: https://dl.acm.org/citation.cfm?id=2992782&preflayout=flat

2013: https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf?wptouch_preview_theme=enabled

2. Drehen von Festplatten

Spinning HDDs haben unterschiedliche Eigenschaften. Aus Sicherheitsgründen und zur Vereinfachung empfehle ich die Annahme, dass sie die gleiche praktische Unsicherheit aufweisen wie Flash-basierte Speicher.

Es sei denn, Sie haben spezifische Beweise, die Sie eindeutig nicht haben. Ich habe keine Vergleichszahlen für sich drehende Festplatten.

Eine Festplatte hinterlässt möglicherweise einen unvollständig geschriebenen Sektor mit einer schlechten Prüfsumme, was später zu einem Fehler beim Lesen führt. Im Großen und Ganzen wird dieser Fehlermodus von Festplatten vollständig erwartet. native Linux-Dateisysteme wurden unter diesem Gesichtspunkt entwickelt. Sie zielen darauf ab, den Vertrag von fsync() angesichts dieser Art von Stromausfallfehler beizubehalten. (Wir möchten wirklich, dass dies auf SSDs garantiert ist).

Ich bin mir jedoch nicht sicher, ob Linux-Dateisysteme dies in allen Fällen erreichen oder ob dies überhaupt möglich ist.

Der nächste Start nach dieser Art von Fehler erfordert möglicherweise eine Reparatur des Dateisystems. Da es sich um Linux handelt, ist es möglich, dass die Dateisystemreparatur einige Fragen stellt, die Sie nicht verstehen. Sie können nur Y drücken und hoffen, dass sie sich von selbst erledigt.

2.1 Wenn Sie den fsync () - Vertrag nicht kennen

Der Vertrag mit fsync () ist eine Quelle für gute und schlechte Nachrichten. Sie müssen zuerst die guten Nachrichten verstehen.

Gute Nachrichten: fsync() ist gut dokumentiert als die richtige Methode zum Schreiben von Dateidaten, z. wenn Sie auf "Speichern" klicken. Und es ist allgemein bekannt, dass z.B. Texteditoren müssen vorhandene Dateien atomar mit rename() ersetzen. Dies soll sicherstellen, dass Sie immer entweder die alte Datei behalten oder die neue Datei erhalten (die vor dem Umbenennen fsync() ed war). Sie möchten nicht mit einer halbgeschriebenen Version der neuen Datei zurückbleiben.

Schlechte Nachrichten: Seit vielen Jahren kann das Aufrufen von fsync () auf dem beliebtesten Linux-Dateisystem das gesamte System für zehn Sekunden hängen lassen. Da Anwendungen nichts dagegen tun können, war es sehr üblich, rename () ohne fsync () optimistisch zu verwenden, was auf diesem Dateisystem relativ zuverlässig zu sein schien.

Daher gibt es Anwendungen, die fsync () nicht korrekt verwenden.

Die nächste Version dieses Dateisystems vermied im Allgemeinen das Hängen von fsync () - zur gleichen Zeit, als es begann, sich auf die korrekte Verwendung von fsync () zu verlassen.

Das ist alles ziemlich schlecht. Das Verständnis dieser Geschichte wird wahrscheinlich nicht durch den abweisenden Ton und die Beschimpfung unterstützt, die von vielen der widersprüchlichen Kernel-Entwickler verwendet wurden.

Die aktuelle Auflösung ist das derzeit beliebteste Linux-Dateisystem standardmäßig wird das Muster rename () unterstützt, ohne dass fsync () erforderlich ist. implementiert "Bug-for-Bug-Kompatibilität" mit der vorherigen Version. Dies kann mit der Mount-Option noauto_da_alloc Deaktiviert werden.

Dies ist kein vollständiger Schutz. Grundsätzlich wird das anstehende IO zum Zeitpunkt des Umbenennens () gelöscht, es wird jedoch nicht darauf gewartet, dass das IO) vor dem Umbenennen abgeschlossen wird. Dies ist viel besser als z Ein 60-Sekunden-Gefahrenfenster! Siehe auch die Antwort auf Welche Dateisysteme benötigen fsync () für die Absturzsicherheit, wenn eine vorhandene Datei durch rename () ersetzt wird?

Einige weniger beliebte Dateisysteme bieten keinen Schutz. XFS lehnt ab dazu. Und UBIFS hat es auch nicht implementiert, anscheinend könnte es akzeptiert werden, erfordert aber viel Arbeit, um es möglich zu machen. Auf derselben Seite wird darauf hingewiesen, dass UBIFS mehrere andere "TODO" -Probleme für die Datenintegrität aufweist, einschließlich des Stromausfalls. UBIFS ist ein Dateisystem, das direkt im Flash-Speicher verwendet wird. Ich stelle mir vor, dass einige der Schwierigkeiten, die UBIFS beim Flash-Speicher erwähnt, für die SSD-Fehler relevant sein könnten.

9
sourcejedi

Auf einem leicht geladenen System lässt der Kernel neu geschriebene Dateidaten nach einer write() etwa 30 Sekunden lang im Seiten-Cache liegen, bevor sie auf die Festplatte geschrieben werden, um sie für den Fall zu optimieren, in dem sie gelöscht werden oder bald wieder geändert.

Linux dirty_expire_centisecs Ist standardmäßig 3000 (30 Sekunden) und steuert, wie lange es dauert, bis neu geschriebene Daten "ablaufen". (Siehe https://lwn.net/Articles/322823/ ).

Weitere verwandte Tunables finden Sie unter https://www.kernel.org/doc/Documentation/sysctl/vm.txt und bei Google nach weiteren Informationen. (z. B. Google auf dirty_writeback_centisecs).

Der Linux-Standard für /proc/sys/vm/dirty_writeback_centisecs Ist 500 (5 Sekunden) . PowerTop empfiehlt, ihn auf 1500 (15 Sekunden) einzustellen, um den Stromverbrauch zu senken .


Durch verzögertes Zurückschreiben hat der Kernel auch Zeit, um zu sehen, wie groß eine Datei sein wird, bevor er mit dem Schreiben auf die Festplatte beginnt. Dateisysteme mit verzögerter Zuweisung (wie XFS und wahrscheinlich auch andere heutzutage) wählen nicht einmal aus, wo auf der Festplatte die Daten einer neu geschriebenen Datei gespeichert werden sollen, bis dies erforderlich ist, unabhängig davon, ob Speicherplatz für den Inode selbst zugewiesen wird. Dies reduziert die Fragmentierung, indem vermieden wird, dass der Start einer großen Datei beispielsweise in einem Abstand von 1 MB zwischen anderen Dateien liegt.

Wenn viele Daten geschrieben werden, kann das Zurückschreiben auf die Festplatte durch einen Schwellenwert für die Anzahl der fehlerhaften (noch nicht mit der Festplatte synchronisierten) Daten im Seitencache ausgelöst werden.

Wenn Sie jedoch nicht viel anderes tun, leuchtet Ihre Festplattenaktivitätsanzeige 5 (oder 15) Sekunden lang nicht auf, nachdem Sie auf Speichern für eine kleine Datei geklickt haben.


Wenn Ihr Editor nach dem Schreiben der Datei fsync() verwendet hat, schreibt der Kernel diese unverzüglich auf die Festplatte. (Und fsync wird erst zurückkehren, wenn die Daten tatsächlich auf die Festplatte gesendet wurden.).


Schreib-Caching innerhalb Die Festplatte kann auch eine Sache sein, aber Festplatten versuchen normalerweise, ihren Schreib-Cache so schnell wie möglich in den permanenten Speicher zu übertragen, im Gegensatz zu den Seiten-Cache-Algorithmen von Linux. Festplattenschreibcaches sind eher ein Speicherpuffer, um kleine Schreibausbrüche zu absorbieren, aber möglicherweise auch, um Schreibvorgänge zugunsten von Lesevorgängen zu verzögern und der Festplatte Firmware-Raum zu geben, um ein Suchmuster zu optimieren (z. B. zwei in der Nähe befindliche Schreibvorgänge oder Lesevorgänge anstelle von einem , dann weit weg suchen, dann zurück suchen.)

Auf einer rotierenden (magnetischen) Festplatte können einige Suchverzögerungen von jeweils 7 bis 10 ms auftreten, bevor Daten von einem SATA-Schreibbefehl tatsächlich vor dem Ausschalten geschützt sind, wenn vor dem Schreiben anstehende Lese-/Schreibvorgänge vorhanden waren. (Einige andere Antworten auf diese Frage gehen detaillierter auf Festplattenschreibcaches und Schreibbarrieren ein, mit denen Journall-FSes Korruption vermeiden können.)

5
Peter Cordes