Werden Dateibearbeitungen in Linux direkt auf der Festplatte gespeichert?

Wenn ich den Computer sofort ausschalte, nachdem ich eine Datei bearbeitet und gespeichert habe, 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 die Daten einfach zwischenspeichert, der Anwendung mitteilt (anlügt), dass der Schreibvorgang durchlaufen wurde, und den Schreibvorgang später tatsächlich durchführt. Dies ist besonders nützlich, wenn gleichzeitig andere Festplattenaktivitäten stattfinden:Das Betriebssystem kann Lesevorgänge priorisieren und die Schreibvorgänge später ausführen. Es kann auch die Notwendigkeit eines tatsächlichen Schreibens vollständig beseitigen, z. B. in dem Fall, in dem eine temporäre Datei danach schnell entfernt wird.

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

Natürlich hat ein solches Caching den Nachteil, den Sie bemerken, 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 jedoch nicht wirklich auf der Festplatte war. Deshalb gibt es die fsync() Systemaufruf, der erst zurückkehren soll, nachdem die Datei tatsächlich auf der Platte angekommen ist. Ihr Redakteur 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 möglicherweise die gleichen Lügen erzählt und sagt, 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 möglicherweise kein Weg daran vorbei.

Zusätzlich zu fsync() , gibt es auch die sync() und syncfs() Systemaufrufe, die das System auffordern, sicherzustellen, dass alle systemweiten Schreibvorgänge oder alle Schreibvorgänge auf einem bestimmten Dateisystem auf der Platte angekommen sind. Das Dienstprogramm sync kann verwendet werden, um diese aufzurufen.

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

Was bei einem Stromausfall 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. Allein das Erweitern einer Datei auf eine größere Größe erfordert das Zuweisen neuer Datenblöcke, und sie müssen irgendwo markiert werden.

Wie ein Dateisystem mit Metadatenänderungen und der Reihenfolge zwischen Metadaten und Datenschreibvorgängen umgeht, ist sehr unterschiedlich. Z. B. mit ext4 , wenn Sie das Mount-Flag data=journal setzen , dann gehen alle Schreibvorgänge – sogar Datenschreibvorgänge – durch das Journal und sollten ziemlich sicher sein. Das bedeutet auch, dass sie zweimal geschrieben werden, sodass die Leistung abnimmt. Die Standardoptionen versuchen, die Schreibvorgänge so zu ordnen, dass sich die Daten auf der Festplatte befinden, bevor die Metadaten aktualisiert werden. Andere Optionen oder andere Dateisysteme können besser oder schlechter sein; Ich werde nicht einmal eine umfassende Studie versuchen.

In der Praxis sollte die Datei auf einem leicht belasteten System innerhalb weniger Sekunden auf der Festplatte landen. Wenn Sie es mit Wechseldatenträgern zu tun haben, hängen Sie das Dateisystem aus, bevor Sie das Medium ziehen, um sicherzustellen, dass die Daten tatsächlich an das Laufwerk gesendet werden und keine weiteren Aktivitäten stattfinden. (Oder lassen Sie das Ihre GUI-Umgebung für Sie erledigen.)

Es gibt ein extrem einfache Möglichkeit zu beweisen, dass es nicht kann Es stimmt zwar, dass Dateibearbeitungen immer direkt auf der Festplatte gespeichert werden, nämlich die Tatsache, dass es Dateisysteme gibt, die nicht von vornherein von einer Festplatte unterstützt werden . Wenn ein Dateisystem nicht hat an erster Stelle eine Festplatte, dann kann es möglicherweise nicht Schreiben Sie die Änderungen jemals auf die Festplatte .

Einige Beispiele sind:

• tmpfs , ein Dateisystem, das nur im RAM (genauer gesagt im Buffer-Cache) existiert
• ramfs , ein Dateisystem, das nur im RAM existiert
• beliebig Netzwerkdateisystem (NFS, CIFS/SMB, AFS, AFP, …)
• beliebig virtuelles Dateisystem (sysfs , procfs , devfs , shmfs , …)

Aber selbst für plattengestützte Dateisysteme gilt dies normalerweise nicht. Die Seite So beschädigt man eine SQLite-Datenbank hat ein Kapitel namens Fehler bei der Synchronisierung die viele verschiedene Möglichkeiten beschreibt, wie Schreibvorgänge (in diesem Fall Commits in eine SQLite-Datenbank) nicht auf der Festplatte ankommen können. SQLite hat auch ein Whitepaper, das die vielen Hürden erklärt, durch die Sie springen müssen, um Atomic Commit In SQLite zu garantieren . (Beachten Sie, dass Atomic Write ist ein viel schwierigeres Problem als nur Schreiben , aber natürlich ist das Schreiben auf die Festplatte ein Teilproblem des atomaren Schreibens, und Sie können auch viel über dieses Problem in diesem Artikel lernen.) Dieser Artikel enthält einen Abschnitt über Dinge, die schief gehen können der einen Unterabschnitt über Unvollständige Datenträgerlöschungen enthält die einige Beispiele für subtile Feinheiten geben, die verhindern könnten, dass ein Schreibvorgang die Festplatte erreicht (z laut ATA-Spezifikation sogar legal sein, weil sie diesbezüglich mehrdeutig formuliert ist).

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. Dasselbe gilt, wenn Sie einen USB-Speicher entfernen, bevor er entfernt werden kann.

Die meisten Systeme bieten auch die Option, Schreibvorgänge synchron zu machen. Das bedeutet, dass die Daten auf der Festplatte sind, bevor eine Anwendung eine Erfolgsbestätigung erhält, auf Kosten der Verlangsamung.

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