Bei manchen Dateisystemen ist es beim Erstellen einer Datei notwendig, fsync() nicht nur für die Datei selbst, sondern auch für das übergeordnete Verzeichnis aufzurufen, um die Dateierstellung dauerhaft zu machen. Andernfalls könnte der Verzeichniseintrag bei einem unsauberen Unmount verloren gehen; der Datei-Inode würde verwaist.
Gilt das auch für ext4 oder kümmert sich das Journal darum?
Viele Anwendungen (z. B. vim, wie von strace überprüft) scheinen fsync nur für die Datei aufzurufen. Ist das sicher?
Update: InVerpflichten 14ece1028b3ed53ffec1b1213ffc6acaf79ad77czum Kernel, ext4 wurde speziell so geändert, dassmit deaktiviertem Journaling, der Eintrag im übergeordneten Verzeichnis wird automatisch mit fsync() bearbeitet, wenn die Datei selbst mit fsync() bearbeitet wird. Aber was ist mit aktiviertem Journaling? Ist das Verzeichnis-fsync() implizit, da es Teil derselben Transaktion ist wie die Erstellung des neuen Inodes?
Antwort1
Ich würde teilweise sagen, dass es darauf ankommt, da die Journaloptionen von ext4 so geändert werden können, dass ganze Dateien oder nur Metadaten protokolliert werden, und ob diese sofort festgeschrieben werden oder nicht, hängt teilweise von den Hardwarekonfigurationen ab.
Falls ext4 zumindest mit Metadaten-Journaling gemountet ist und das Subsystem keine Schreibvorgänge zwischenspeichert, würde ich vorschlagen, dass Sie das Verzeichnis nicht per Fsync synchronisieren.
Doch vonLarssons „ext4 vs fsync“:
Es ist zu beachten, dass POSIX und sogar ext4 keine Garantie dafür geben, dass die Datei einen Systemabsturz übersteht, selbst wenn fsync verwendet wird.
Keine vollständige Antwort, aber der betreffende Blogbeitrag geht ausführlich auf Probleme mit Journaling und Datenverlust ein. Obwohl er nicht neu ist, ist er meiner Meinung nach immer noch ein Beispiel für den aktuellen Status von ext4 und seine Kommentare dazu, wann fsync verwendet werden sollte und wann nicht, sind berechtigt.