rename und verzögerte Allokation

12/03/2009 - 10:29 von Michael Schuerig | Report spam
In einer aktuellen Diskussion[*] über das Verhalten von
(Linux-)Dateisystem hat Theodore Ts'o die folgenden beiden
Aufrufsequenzen genannt, von denen nur die zweite Datenkonsistenz
garantiert.

(A)
open and read file ~/.kde/foo/bar/baz
fd = open("~/.kde/foo/bar/baz.new", O_WRONLY|O_TRUNC|O_CREAT)
write(fd, buf-of-new-contents-of-file, size-of-new-contents-of-file)
close(fd)
rename("~/.kde/foo/bar/baz.new", "~/.kde/foo/bar/baz")

(B)
open and read file ~/.kde/foo/bar/baz
fd = open("~/.kde/foo/bar/baz.new", O_WRONLY|O_TRUNC|O_CREAT)
write(fd, buf-of-new-contents-of-file, size-of-new-contents-of-file)
fsync(fd) and check the error return from the fsync
close(fd)
rename("~/.kde/foo/bar/baz.new", "~/.kde/foo/bar/baz")

Eine entscheidende Annahme in beiden Fàllen ist, dass das Filesystem
Operationen nicht unmittelbar (synchron) auf der Platte ausführt,
sondern zunàchst zwischenspeichert. Böse Dinge passieren, wenn bei (A)
das System nach dem rename abstürzt, bevor die zwischengespeicherten
Blöcke geschrieben wurden. In dieser Situation verweist der Name
~/.kde/foo/bar/baz anschliessend offenbar auf eine leere Datei.

Obwohl sich viele zu diesem Thema geàußert haben, ist mir daraus nicht
vollstàndig klar geworden, warum genau das Problem entsteht. Erklàren
könnte ich mir das beobachtete Verhalten nur dann, wenn rename immer
synchron ausgeführt wird. Dann gibt es einen Zeitraum zwischen dem
Aufruf von rename und dem Schreiben der zwischengespeicherten Daten, in
dem der Dateiname auf eine (noch) nicht existierende Datei (inode?)
verweist. -- Ist das so?

Falls das so ist, wàre dann nicht die saubere Lösung, dass das
Filesystem die Reihenfolge der Operationen garantiert, dass also write
physikalisch ausgeführt wird, bevor rename ausgeführt wird -- oder dass
das beobachtbare Verhalten davon ununterscheidbar ist. Ich nehme an,
dass FS-Operationen dadurch langsamer würden, aber würden sie soviel
langsamer, wie ein erzwungenes fsync auf Anwendungsebene erzwingen
würde?

Michael

[*] https://bugs.edge.launchpad.net/ubu...bug/317781

Michael Schuerig
mailto:michael@schuerig.de
http://www.schuerig.de/michael/
 

Lesen sie die antworten

#1 mlelstv
12/03/2009 - 13:44 | Warnen spam
Michael Schuerig writes:

Obwohl sich viele zu diesem Thema geàußert haben, ist mir daraus nicht
vollstàndig klar geworden, warum genau das Problem entsteht. Erklàren
könnte ich mir das beobachtete Verhalten nur dann, wenn rename immer
synchron ausgeführt wird.



Es reicht aus, wenn es weniger verzoegert wird als das Schreiben
der Daten. Es muss auch nicht wirklich ausgefuehrt werden, es reicht,
wenn die rename-Operation im Journal steht, so dass sie beim Replay des
Journals ausgefuehrt wird.

Und genau das geschieht. Das Journal wird zwar nicht synchron geschrieben
aber relativ zeitnah. Die Daten werden wesentlich spaeter geschrieben,
damit man die Platzierung der Daten optimieren kann.


Falls das so ist, wàre dann nicht die saubere Lösung, dass das
Filesystem die Reihenfolge der Operationen garantiert, dass also write
physikalisch ausgeführt wird, bevor rename ausgeführt wird



So ist es, und das aeltere ext3-Filesystem im Modus data=ordered
macht auch genau das. Im Modus data=writeback hat es dieselben
Probleme.

Bei ext4 werden (oder wurden?) anscheinend die Garantien von data=ordered
nicht korrekt umgesetzt, wenn man den Berichten trauen darf.


[...] Ich nehme an,
dass FS-Operationen dadurch langsamer würden, aber würden sie soviel
langsamer, wie ein erzwungenes fsync auf Anwendungsebene erzwingen
würde?



Fuer die Geschwindigkeit waere das in der Theorie ungefaehr das Gleiche,
fsyncs sind geringfuegig langsamer, weil da noch die Latenzen der
Systemaufrufe hinzukommen. In der Praxis kann ein fsync auf Anwendungsebene
wesentlich langsamer sein, weil es z.B. bei ext3 wartet bis alle
Daten von allen geschriebenen Dateien auf der Platte sind.

Der wesentliche Nachteil von fsync liegt aber darin, dass die Anwendung
warten muss und die Vorgànge nicht im Hintergrund ablaufen koennen.

Michael van Elst
Internet:
"A potential Snark may lurk in every tree."

Ähnliche fragen