Warum hat das Ausschalten meines Rechners nach einem schlechten Start meine Dateien gespeichert?

Klassische Situation: Ich lief schlecht rmund merkte sofort danach, dass ich die falschen Dateien entfernt hatte. (Nichts kritisches und ich hatte erträglich neue Backups, aber immer noch ärgerlich.)

Da ich wusste, dass weitere Festplattenaktivität mein Feind war, wenn ich die Dateien mit extundeleteoder ohne solche Tools wiederherstellen wollte, schaltete ich die Maschine sofort physisch aus (dh mit dem Ein- / Ausschalter, nicht mit haltoder ohne einen solchen Befehl). Dies war ein Laptop, auf dem keine wichtigen Aufgaben ausgeführt wurden oder etwas offen war. Es war also eine akzeptable Operation. (Übrigens habe ich seitdem erfahren, dass das erste, was in einer solchen Situation zu tun ist, zu schätzen ist, ob die fehlenden Dateien noch von einem Prozess geöffnet werden können. Https://unix.stackexchange.com/a/101247 - Wenn dies der Fall ist, sollten Sie sie auf diese Weise wiederherstellen, anstatt die Maschine auszuschalten.)

Nachdem die Maschine heruntergefahren war, dachte ich eine Weile nach und entschied, dass sich die Zeit für das Booten eines Live-Systems für eine ordnungsgemäße Forensik nicht lohnt. Also habe ich die Maschine wieder hochgefahren. Und dann stellte ich fest, dass sich meine Dateien noch auf der Festplatte befanden: Die wurden rmnicht auf die Festplatte übertragen, bevor ich sie heruntergefahren hatte. Ich machte einen kleinen Tanz und dankte dem Gott der Sysadmins für seine unerwartete Vergebung.

Meine Frage ist nun zu verstehen, wie dies möglich war und wie lange es normalerweise dauert, bis eine rmDatei tatsächlich auf die Festplatte übertragen wird. Ich weiß, dass Festplatten-E / A nicht sofort gelöscht wird, sondern einige Zeit im Speicher verbleibt, aber ich dachte, dass das Festplattenjournal schnell sicherstellen würde, dass ausstehende Vorgänge nicht vollständig verloren gehen. https://unix.stackexchange.com/a/78766 deutet anscheinend auf einen separaten Mechanismus zum Leeren verschmutzter Seiten und zum Leeren von Journalvorgängen hin, gibt jedoch keine ausreichenden Informationen darüber, wie das Journal für eine rmund die erwartete Verzögerung davor beteiligt sein würde Operationen werden gespült.

Einige weitere Details: Die Daten befanden sich in einer ext4-Partition innerhalb eines LUKS-Volumes, und beim Booten des Computers sah ich Folgendes in syslog:

Sep 24 10:24:58 gamma kernel: [   11.457007] EXT4-fs (dm-0): 1 orphan inode deleted
Sep 24 10:24:58 gamma kernel: [   11.458393] EXT4-fs (dm-0): recovery complete
Sep 24 10:24:58 gamma kernel: [   11.482475] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

aber ich bin nicht sicher, ob es mit dem verwandt ist rm.

Eine andere Frage wäre, ob es eine Möglichkeit gibt, den Kernel anzuweisen, keine der ausstehenden Festplattenoperationen auszuführen (sondern sie beispielsweise irgendwo abzulegen), anstatt die Maschine auszuschalten. (Natürlich klingt es gefährlich, die ausstehenden Vorgänge nicht auszuführen, aber dies würde passieren, wenn die Maschine ohnehin heruntergefahren wird, und in einigen Fällen könnte es Ihnen helfen.) Dies wäre natürlich "sauberer" und auch interessant Zum Beispiel für Remote-Server, bei denen ein physisches Herunterfahren nicht einfach ist.

Es hört sich so an, als hättest du einen guten Überblick darüber, was passiert ist.

Ja, da Sie das System vor dem Festschreiben der Änderungen auf der Festplatte ausgeschaltet haben, waren diese beim Hochfahren vorhanden.

Das System speichert alle Schreibvorgänge zwischen, bevor sie auf die Festplatte geschrieben werden. Es gibt verschiedene Optionen, die dieses Verhalten steuern. Alle befinden sich unter /proc/sys/vm/dirty_* ^{[ kernel doc ]} . Sofern von einer Anwendung nicht explizit eine ^Leerung über fsync() ^{[ man 2 fsync ] durchgeführt wird} , werden die Daten festgeschrieben, wenn sie entweder alt genug sind oder der Schreibcache voll ist.
Die oben verwendete Definition von "Daten" umfasst die Änderung des Verzeichniseintrags zum Löschen der Datei.

Nun, was das Tagebuch betrifft, so ist dies eines der häufigsten Missverständnisse darüber, wofür das Tagebuch gedacht ist. Mit einem Journal soll nicht sichergestellt werden, dass Änderungen wiedergegeben werden oder dass keine Daten verloren gehen. Der Zweck eines Journals besteht darin, eine Beschädigung des Dateisystems selbst und nicht der darin enthaltenen Dateien zu verhindern. Das Journal enthält lediglich Informationen zu den vorgenommenen Änderungen und nicht (normalerweise) die vollständigen Daten der Änderung. Die genauen Details hängen vom Dateisystem und vom Journalmodus ab. Für ext3 / 4 siehe die datamount Option in man 8 mount.

So beantworten Sie Ihre Zusatzfrage, ob es eine Möglichkeit gibt, ausstehende Schreibvorgänge ohne Neustart zu verhindern:

Wenn Sie den Kernel-Quellcode schnell durchlesen, können Sie anscheinend mit dem uBefehl magic sysrq ^{([ wikipedia ], [ kernel doc ])} einen Notfall-Remount-Schreibschutz ausführen. Es sieht so aus, als würden alle Volumes ohne Synchronisierungsvorgang sofort wieder bereitgestellt, wenn sie schreibgeschützt sind .

Drücken Sie dazu einfach Alt+ SysRq+ u.

Von: https://www.kernel.org/doc/Documentation/filesystems/ext4.txt

commit = nrsec (*) Ext4 kann angewiesen werden, alle 'nrsec' Sekunden alle seine Daten und Metadaten zu synchronisieren. Der Standardwert ist 5 Sekunden. Dies bedeutet, dass Sie, wenn Sie Ihre Energie verlieren, so viel verlieren wie die letzten 5 Sekunden der Arbeit (Ihr Dateisystem wird jedoch dank der Aufzeichnung nicht beschädigt). Dieser Standardwert (oder ein niedriger Wert) beeinträchtigt die Leistung, ist jedoch gut für die Datensicherheit. Das Setzen auf 0 hat den gleichen Effekt wie das Belassen der Standardeinstellung (5 Sekunden). Wenn Sie einen sehr großen Wert festlegen, wird die Leistung verbessert.

Lesen Sie auch hier, wie Sie sie leeren : Wie leeren Sie die Puffer und den Cache auf einem Linux-System?

Zitiert aus dem obigen Link:

HINWEIS: Bereinigen Sie den Speicher von unnötigen Dingen (Kernerl 2.6.16 oder neuer). Stellen Sie immer sicher, dass Sie zuerst die Synchronisierung ausführen, um nützliche Dinge auf die Festplatte zu übertragen !!!

To free pagecache:

$ echo 1 > /proc/sys/vm/drop_caches

To free dentries and inodes:

$ echo 2 > /proc/sys/vm/drop_caches

To free pagecache, dentries and inodes:

$ echo 3 > /proc/sys/vm/drop_caches