Kann das Dateisystem inkonsistent werden, wenn es beim Verschieben einer Datei unterbrochen wird?

Ich habe zwei Ordner auf derselben Partition (EXT2) Wenn ich mv folder1/file folder2und eine Unterbrechung auftreten (z. B. Stromausfall), könnte das Dateisystem jemals inkonsistent werden?

Ist die mvOperation nicht atomar?

Update: Bisher habe ich im IRC folgende Perspektiven bekommen:

1. es ist atomar, so dass Inkonsistenzen nicht auftreten können
2. Zuerst kopieren Sie den Verzeichniseintrag in das neue Verzeichnis und löschen dann den Eintrag im vorherigen Verzeichnis, sodass möglicherweise die Inkonsistenz besteht, dass auf eine Datei zweimal verwiesen wird, die Anzahl der Verweise jedoch 1 beträgt
3. Es löscht zuerst den Zeiger und kopiert dann den Zeiger, sodass die Inkonsistenz darin besteht, dass die Datei die Referenz 0 hat

Kann das jemand klären?

Lassen Sie uns zuerst einige Mythen zerstreuen.

es ist atomar, so dass Inkonsistenzen nicht auftreten können

Das Verschieben einer Datei innerhalb desselben Dateisystems (dh des renameSystemaufrufs) ist in Bezug auf die Softwareumgebung unteilbar. Atomicity bedeutet, dass jeder Prozess, der nach der Datei sucht, diese entweder am alten oder am neuen Speicherort sieht. Keiner der Prozesse kann feststellen, dass die Datei eine andere Linkanzahl aufweist oder dass die Datei im Quellverzeichnis vorhanden ist, nachdem sie im Zielverzeichnis vorhanden ist, oder dass die Datei im Zielverzeichnis nicht vorhanden ist, nachdem sie in der Quelle nicht vorhanden ist Verzeichnis.

Wenn das System jedoch aufgrund eines Fehlers, eines Festplattenfehlers oder eines Stromausfalls abstürzt, kann nicht garantiert werden, dass sich das Dateisystem in einem konsistenten Zustand befindet, geschweige denn, dass die Verschiebung nicht zur Hälfte abgeschlossen ist. Linux bietet im Allgemeinen keine Garantie für die Atomizität in Bezug auf Hardware-Ereignisse.

Zuerst kopieren Sie den Verzeichniseintrag in das neue Verzeichnis und löschen dann den Eintrag im vorherigen Verzeichnis, sodass möglicherweise die Inkonsistenz besteht, dass auf eine Datei zweimal verwiesen wird, die Anzahl der Verweise jedoch 1 beträgt

Dies bezieht sich auf eine bestimmte Implementierungstechnik. Da sind andere.

Es kommt also vor, dass ext2 unter Linux (ab Kernel 3.16) diese spezielle Technik verwendet. Dies bedeutet jedoch nicht, dass der Festplatteninhalt die Sequenz [alter Speicherort] → [beide Speicherorte] → [neuer Speicherort] durchläuft, da die beiden Vorgänge (Neuen Eintrag hinzufügen, Alten Eintrag entfernen) auch auf Hardwareebene nicht uneinheitlich sind : Es ist möglich, dass einer von ihnen unterbrochen wird und das Dateisystem in einem inkonsistenten Zustand bleibt. (Hoffentlich repariert fsck es.) Außerdem kann die Blockebene Schreibvorgänge neu anordnen, sodass die erste Hälfte kurz vor dem Absturz auf die Festplatte geschrieben werden kann und die zweite Hälfte dann nicht ausgeführt worden wäre.

Es wird nie beobachtet, dass der Referenzzähler von 1 abweicht, solange das System nicht abstürzt (siehe oben), aber diese Garantie gilt nicht für einen Systemabsturz.

Es löscht zuerst den Zeiger und kopiert dann den Zeiger, sodass die Inkonsistenz darin besteht, dass die Datei die Referenz 0 hat

Dies bezieht sich wiederum auf eine bestimmte Implementierungstechnik. Eine baumelnde Datei kann nicht beobachtet werden, wenn das System nicht abstürzt. Dies ist jedoch zumindest in einigen Konfigurationen eine mögliche Folge eines Systemabsturzes.

Laut einem Blog-Beitrag von Alexander Larsson gibt ext2 keine Garantie für die Konsistenz bei einem Systemabsturz, ext3 jedoch im data=orderedModus. (Beachten Sie, dass es in diesem Blog-Beitrag nicht um sich renameselbst geht, sondern um die Kombination aus Schreiben in eine Datei und Aufrufen renamedieser Datei.)

Theodore Ts'o, der Hauptautor der Dateisysteme ext2, ext3 und ext4, schrieb einen Blogbeitrag zum selben Thema . In diesem Blogbeitrag werden die Atomizität (nur in Bezug auf die Softwareumgebung) und die Haltbarkeit (Atomizität in Bezug auf Abstürze sowie eine Garantie für die Verpflichtung, dh das Wissen, dass die Operation ausgeführt wurde) erörtert . Leider kann ich allein keine Informationen zur Atomizität in Bezug auf Abstürze finden. Die Haltbarkeitsgarantien für ext4 setzen jedoch voraus, dass sie renameatomar sind. Die Kerneldokumentation für ext4 besagt, dass ext4 mit der auto_da_allocOption (die in modernen Kerneln die Standardeinstellung ist) sowie ext4 eine Haltbarkeitsgarantie für a writegefolgt von a bietenrename, was impliziert, dass renamein Bezug auf Hardware-Abstürze atomar ist.

Für Btrfs, eine , renamedie eine vorhandene Datei überschrieben wird garantiert in Bezug auf Abstürze Atom sein, aber eine , renamedie keine Datei überschrieben werden können vorhandene in keinem der beiden Datei oder beide Dateien führen.

Zusammenfassend lässt sich sagen, dass die Antwort auf Ihre Frage lautet, dass eine Datei nicht nur in Bezug auf Abstürze auf ext2 nicht atomar verschoben wird, sondern auch nicht garantiert wird, dass die Datei in einem konsistenten Zustand bleibt (obwohl Fehler, fsckdie nicht repariert werden können, selten sind). so ziemlich nichts ist, weshalb bessere Dateisysteme erfunden wurden. Ext3, ext4 und btrfs bieten begrenzte Garantien.

Der Umbenennungsvorgang ist auf jedem Dateisystem sehr schnell, so dass es unwahrscheinlich ist, dass er unterbrochen wird. Auf einem klassischen Dateisystem kann er jedoch unterbrochen werden. Wenn zuerst der Ziellink erstellt wird, können zwei Links in einer Datei verbleiben. Dies ist zulässig. Die Datei glaubt jedoch, nur eine zu haben, was zu Problemen führen kann, wenn eine Datei später gelöscht wird. Wenn die Quellverknüpfung jedoch zuerst entfernt wird, kann die Datei verloren gehen. Wenn Sie fsck ausführen, wird in der Regel eine der beiden Bedingungen erkannt und behoben. Wenn die Datei jedoch verloren geht, wird sie in einem "Fundsachen" -Verzeichnis mit einem beliebigen Namen und nicht am gewünschten Speicherort abgelegt. Wenn zwei Links vorhanden sind, wird die Anzahl der Links einfach berechnet aktualisiert werden, sodass die Datei an zwei Speicherorten vorhanden ist, wenn das Dateisystem dies unterstützt.

Wenn Sie ein Dateisystem benötigen, das bei Stromausfällen robust ist, sollten Sie ein Journal-Dateisystem wie NTFS, EXT3 oder XFS verwenden. Die meisten modernen Systeme verwenden standardmäßig ein Journal-Dateisystem. Beachten Sie jedoch, dass FAT kein Journal-Dateisystem ist, wenn Sie es für externe Laufwerke verwenden.

Ein Journal-Dateisystem verwendet ein "Double-Entry" -System. Es schreibt die beabsichtigte Verschiebung in die Journaldatei und führt dann die Verschiebung durch. Wenn das Dateisystem beim Start überprüft wird und unterbrochen wurde, stellt es fest, dass die Verschiebung nicht abgeschlossen wurde, und führt sie anschließend erneut aus.

Es gibt zwei Arten von Journal-Dateisystemen: Metadaten-Journaling und Full-Journaling. Metadaten-Journaling bedeutet, dass Änderungen am Dateiinhalt im Journalsystem nicht protokolliert werden (sodass Sie möglicherweise den Inhalt verlieren, wenn Sie in eine Datei schreiben). Wichtige Informationen zum Dateisystem, z. B. der Verzeichnisinhalt, werden jedoch weiterhin protokolliert , Dateieigenschaften usw.

Wenn die Leute davon sprechen, dass der Umbenennungsvorgang atomar ist, meinen sie, dass er nicht während des Übergangs von einem anderen Prozess auf dem System beobachtet werden kann und nicht zur Hälfte abgeschlossen werden kann, indem z. B. der mvBefehl selbst mit unterbrochen wird ^C. Der physische Vorgang des Schreibens in jedes Verzeichnis, dessen Speicherplatz sich möglicherweise an sehr unterschiedlichen Orten auf der Festplatte befindet, kann auf Hardwareebene möglicherweise keine wirklich atomare Operation sein.

Der Vollständigkeit halber werde ich bemerken, dass mit einer Umbenennung auch einige zufällige E / A-Vorgänge verbunden sind, zusätzlich zum Erstellen des neuen Links im Zielverzeichnis und zum Entfernen des alten Links - Aktualisieren der M-Zeit beider Verzeichnisse und möglicherweise Erweitern des Zuordnungsgröße des Zielverzeichnisses, Ändern der ..Verknüpfung und der Verknüpfungsanzahl der übergeordneten Verzeichnisse, wenn die Datei ein Verzeichnis ist. Ich bin mir auch nicht sicher, ob der Zeitpunkt der Datei selbst betroffen ist.

Diese Frage wurde Super User etwas anders gestellt. Die Wikipedia-Seite zum mvBefehl erklärt es auch recht gut:

Das Verschieben von Dateien innerhalb desselben Dateisystems erfolgt im Allgemeinen anders als das Kopieren der Datei und das anschließende Entfernen des Originals. Auf Plattformen, die das Umbenennen von syscall nicht unterstützen, wird dem neuen Verzeichnis ein neuer Link hinzugefügt und das ursprüngliche Verzeichnis gelöscht. Auf die Daten der Datei wird nicht zugegriffen.

Linux hat den Umbenennungs-Syscall und benennt die Datei daher als atomare, dh nicht unterbrechbare Operation um. Nein, das Dateisystem kann in der von Ihnen beschriebenen Situation nicht inkonsistent werden.