Wie lange können Dateisystem-Schreibvorgänge mit ext4 zwischengespeichert werden?

Vor einiger Zeit gab es einige Diskussionen darüber, dass ext4 nach einem unreinen Unmount möglicherweise leere Dateien hinterlässt, was in diesem Artikel ziemlich gut zusammengefasst wurde . Grundsätzlich können Schreibvorgänge aufgrund der verzögerten Zuweisung viel länger als das Standard-Festschreibungsintervall des ext-Journals (5 Sekunden) im Schreibcache gespeichert werden.

Die Probleme scheinen in einem Patch behoben worden zu sein, der in bestimmten Situationen die Blockzuweisung erzwingt und dadurch die Daten standardmäßig nach höchstens 5 Sekunden auf die Festplatte zwingt.

Ich frage mich, was passiert, wenn eine Anwendung vorhandene Teile einer Datei überschreibt, ohne die Datei selbst abzuschneiden oder anzufügen. Wird das auch innerhalb von 5 Sekunden auf die Festplatte gebracht?

Dies scheint eine andere Situation zu sein als das Anhängen an eine Datei: Beim Anhängen ändert sich die Dateigröße. Dies ist eine Metadatenänderung. Daher muss innerhalb von 5 Sekunden ein Journal-Commit durchgeführt werden. Aufgrund von data = orders müssen die Daten aus Sicherheitsgründen zuvor geschrieben werden (andernfalls können Teile der gelöschten Dateien anderer Benutzer für den Eigentümer des angehängten Dokuments angezeigt werden Datei).

Wenn Sie nur Dateidaten überschreiben, gibt es keinen Grund, warum das Schreiben der Daten vor dem Festschreiben des Metadatenjournals erfolgen muss, da die alten Daten demselben Benutzer gehören wie die neuen. Tritt der Schreibvorgang trotzdem vor dem Festschreiben auf, oder kann er länger als das Festschreibungsintervall für das Journal verzögert werden? Wenn ja, wie lange?

Update: Ich weiß, dass all dies irrelevant ist, wenn man das Richtige tut, also fsync () verwendet. (Dies war der Hauptgrund für alle Diskussionen über ext4 und Datenverlust - das Problem betraf nur Anwendungen, die nicht fsync () sind oder nicht im richtigen Moment.) Ich schreibe keine eigene Anwendung, frage ich, weil ich Ich weiß nicht, ob alle meine Anwendungen das Richtige tun, und ich möchte einen ungefähren Zeitrahmen für solche "gefährlichen" Schreibvorgänge kennen. Der Grund für die Frage ist, dass mein Grafiktreiber regelmäßig Kernel-Panics verursacht, und ich möchte wissen, ob ich mir Gedanken über mehr als die letzten 5 Sekunden beim Schreiben von Daten machen muss.

Sie können das Festschreibungsintervall auf einen benutzerdefinierten Wert festlegen, der meines Erachtens eine vorzeichenlose 32-Bit-Ganzzahl von Sekunden sein kann. also ungefähr 4 Milliarden Sekunden oder 136 Jahre. Dies ist über die commitMount-Option möglich, die Sie folgendermaßen ausführen können (dies ist nur ein Beispiel; Sie können dies auch festlegen fstab):

mount /dev/sda1 -t ext4 -o rw,data=writeback,nobh,commit=12345678

Das Festschreibungsintervall basiert nicht auf einer Art von Bedingung, z. B. ob die Daten angehängt werden oder vorhandene Daten überschrieben werden oder was auch immer. Die commitMount-Option (die standardmäßig 5 Sekunden beträgt, wenn Sie die Mount-Option überhaupt nicht angeben) entspricht der folgenden Vorgehensweise in einer Bash-Shell:

#!/bin/bash
while :
do
    echo "Syncing all uncommitted data and journal to disk"
    sync
    sleep 5
done

Nicht verwechseln data=orderedund dieses globale Dateisystem-Synchronisierungsintervall ("Festschreibungsintervall" ist möglicherweise ein weniger aussagekräftiger Begriff für diejenigen von uns, die die Funktionalität des Befehlszeilenprogramms verstehen. syncIn diesem Fall wird es möglicherweise besser als "Synchronisierungsintervall" bezeichnet). data=orderedHierbei geht es um die Reihenfolge, in der Daten und Metadaten aktualisiert werden (wobei data=writeback"weniger sicher / schneller" und data=journal"sicherer / langsamer" ist). commit=12345678Hierbei geht es um die Häufigkeit, mit der der Dateisystemtreiber selbst eine vollständige Synchronisierung ALLER fehlerhaften Daten / Journale / Metadaten / was auch immer auf den physischen Datenträgern erzwingt. Und Sie können es mit Sicherheit auf 136 Jahre einstellen, wenn Sie möchten, und mit data=writeback,nobhund Programmen mounten , die keine schmutzigen Seiten im RAM aufrufen fsync()oder sync()haben, für ...

Update: Abhängig von Ihrem Kontext bei der Bearbeitung Ihrer Frage würde ich sagen, dass Sie Ihr Dateisystem mit Mount-Optionen data=journal,commit=1oder sogar mit der syncMount-Option ausführen sollten , bis Sie in der Lage sind, die Probleme mit dem Kernel des Grafiktreibers zu lösen. Dadurch wird die maximale Datenintegrität auf Kosten der Leistung aufrechterhalten. Sie sollten dies insbesondere dann tun, wenn Sie häufig Daten auf eine Festplatte schreiben, die Sie sich nicht leisten können, zu verlieren. Dies ist doppelt wichtig, wenn Sie den Apps, die Sie für den fsync()richtigen Einsatz verwenden, nicht "vertrauen" .

Quelle: hier und persönliche Erfahrung

Was auch immer die Antwort auf Ihre Frage ist, es spielt keine Rolle.

Das garantierte exponierte Verhalten des ext4-Dateisystems ist, dass "Daten nach einem erfolgreichen sync/ fsyncAufruf auf der Disc sein werden ". Wenn Sie also eine Anwendung haben, mit der Sie diese Frage stellen, sollten Sie Synchronisierungsaufrufe an den kritischen Stellen einfügen, an denen die Datenintegrität sichergestellt werden muss. Wenn Sie ein Benutzer sind, der sich wegen desselben Problems Sorgen macht, können Sie das syncBefehlszeilendienstprogramm aufrufen, bevor Sie das gefährliche Verhalten ausführen, das zu einem unsauberen Herunterfahren führen kann.