☰

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

tag-icon • tag-icon filesystems ext4
Wie lange können Dateisystem-Schreibvorgänge mit ext4 zwischengespeichert werden?

Vor einiger Zeit gab es eine Diskussion darüber, dass ext4 möglicherweise leere Dateien nach einem unsauberen Unmount hinterlässt.In diesem Artikel. Aufgrund der verzögerten Zuordnung können Schreibvorgänge grundsätzlich viel länger im Schreibcache gespeichert werden als das Standard-Commit-Intervall des externen Journals (5 Sekunden).

Die Probleme scheinen mit 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 anzuhängen. Wird das auch innerhalb von 5 Sekunden auf die Festplatte gezwungen?

Dies scheint eine andere Situation zu sein als das Anhängen an eine Datei: Beim Anhängen ändert sich die Dateigröße, was eine Änderung der Metadaten darstellt. Daher ist innerhalb von 5 Sekunden ein Journal-Commit erforderlich. Aufgrund von data=ordered müssen die Daten aus Sicherheitsgründen vorher geschrieben werden (sonst könnten Teile gelöschter Dateien anderer Benutzer für den Eigentümer der angehängten Datei angezeigt werden).

Beim bloßen Überschreiben von Dateidaten gibt es keinen Grund, warum das Schreiben der Daten vor dem Metadaten-Journal-Commit erfolgen muss, da die alten Daten demselben Benutzer gehören wie die neuen. Erfolgt das Schreiben also ohnehin vor dem Commit oder kann es länger als das Journal-Commit-Intervall 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 die ganze Diskussion über ext4 und Datenverlust – das Problem betraf nur Anwendungen, die nicht fsync() verwendeten oder nicht im richtigen Moment.) Ich schreibe nicht meine eigene Anwendung, ich frage, weil ich nicht weiß, ob alle meine Anwendungen das Richtige tun, und ich möchte einen ungefähren Zeitrahmen für solche „gefährlichen“ Schreibvorgänge wissen. Der Grund für meine Frage ist, dass mein Grafiktreiber regelmäßig Kernel-Paniken verursacht und ich wissen möchte, ob ich mir über mehr als die letzten 5 Sekunden der Datenschreibvorgänge Sorgen machen muss.

Antwort1

Sie können das Commit-Intervall auf einen benutzerdefinierten Wert einstellen, der meines Wissens bis zu einer 32-Bit-Ganzzahl ohne Vorzeichen in Sekunden betragen kann; also etwa 4 Milliarden Sekunden oder 136 Jahre. Dies ist über die commitMount-Option verfügbar, die Sie wie folgt aktivieren können (dies ist nur ein Beispiel; Sie können dies auch in einstellen fstab):

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

Das Commit-Intervall hängt nicht von irgendwelchen Bedingungen ab, etwa davon, 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 etwa folgender Vorgehensweise in einer Bash-Shell:

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

Verwechseln Sie nicht data=ordereddieses globale Dateisystem-Sync-Intervall ("Commit-Intervall" ist vielleicht ein weniger aussagekräftiger Begriff für diejenigen von uns, die die Funktionalität des Kommandozeilenprogramms verstehen sync, in diesem Fall wäre es vielleicht besser, es "Sync-Intervall" zu nennen). data=orderedEs geht um dieBefehlin dem Daten und Metadaten aktualisiert werden (wobei data=writeback„weniger sicher / schneller“ und data=journal„sicherer / langsamer“ ist). commit=12345678geht es um die Häufigkeit, mit der der Dateisystemtreiber selbst eine VOLLSTÄNDIGE Synchronisierung ALLER fehlerhaften Daten/Journale/Metadaten/was auch immer mit dem physischen Medium erzwingt. Und Sie können es mit Sicherheit auf 136 Jahre einstellen, wenn Sie möchten, und mit data=writeback,nobhProgrammen mounten, die nicht aufrufen fsync()oder sync()fehlerhafte Seiten mehrere Leben lang im RAM haben.

Update: Basierend auf dem Kontext Ihrer Fragebearbeitung 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 die Kernel-Panik Ihres Grafiktreibers beheben können. Dadurch wird die maximale Datenintegrität aufrechterhalten, allerdings auf Kosten der Leistung. Sie sollten dies insbesondere dann tun, wenn Sie häufig Daten auf die Festplatte schreiben, deren Verlust Sie sich nicht leisten können, und das ist doppelt wichtig, wenn Sie den von Ihnen verwendeten Apps nicht „vertrauen“, dass sie fsync()angemessen eingesetzt werden.

Quelle: Hierund persönliche Erfahrung

Antwort2

Wie auch immer die Antwort auf Ihre Frage ausfällt, es spielt keine Rolle.

Dergarantiert exponiertDas Verhalten des ext4-Dateisystems ist, dass „Daten nach einem erfolgreichen sync/ fsync-Aufruf auf der Festplatte sind“. Wenn Sie also eine Anwendung haben, bei der Sie diese Frage stellen, sollten Sie Synchronisierungsaufrufe an den kritischen Punkten einfügen, an denen die Datenintegrität sichergestellt werden muss. Wenn Sie ein Benutzer sind, der sich über dasselbe Problem Sorgen macht, können Sie das syncBefehlszeilenprogramm aufrufen, bevor Sie gefährliche Verhaltensweisen ausführen, die zu einem unsauberen Herunterfahren führen könnten.

verwandte Informationen