Wenn Sie sich nur für ext4 und nicht für ext3 interessieren, würde ich empfehlen, fsync für die neue Datei zu verwenden, bevor Sie die Umbenennung vornehmen. Die fsync-Leistung auf ext4 scheint ohne die sehr langen Verzögerungen viel besser zu sein als auf ext3. Oder es könnte die Tatsache sein, dass Writeback der Standardmodus ist (zumindest auf meinem Linux-System).
Wenn es Ihnen nur wichtig ist, dass die Datei vollständig ist und nicht, wie die Datei im Verzeichnis heißt, müssen Sie nur die neue Datei fsyncen. Es ist nicht nötig, das Verzeichnis auch zu fsyncen, da es entweder auf die neue Datei mit ihren vollständigen Daten oder auf die alte Datei verweist.
Nein.
Sehen Sie sich libeatmydata und diese Präsentation an:
Essen Sie meine Daten:Wie jeder Datei-IO falsch macht
http://www.oscon.com/oscon2008/public/schedule/detail/3172
von Stewart Smith von MySql.
Falls es offline/nicht mehr verfügbar ist, behalte ich eine Kopie davon:
- Das Video hier
- Die Präsentationsfolien (Online-Version der Folien)
Aus der ext4-Dokumentation:
When mounting an ext4 filesystem, the following option are accepted:
(*) == default
auto_da_alloc(*) Many broken applications don't use fsync() when
noauto_da_alloc replacing existing files via patterns such as
fd = open("foo.new")/write(fd,..)/close(fd)/
rename("foo.new", "foo"), or worse yet,
fd = open("foo", O_TRUNC)/write(fd,..)/close(fd).
If auto_da_alloc is enabled, ext4 will detect
the replace-via-rename and replace-via-truncate
patterns and force that any delayed allocation
blocks are allocated such that at the next
journal commit, in the default data=ordered
mode, the data blocks of the new file are forced
to disk before the rename() operation is
committed. This provides roughly the same level
of guarantees as ext3, and avoids the
"zero-length" problem that can happen when a
system crashes before the delayed allocation
blocks are forced to disk.
Gemessen an der Formulierung "kaputte Anwendungen" wird dies von den ext4-Entwicklern definitiv als schlechte Praxis angesehen, aber in der Praxis ist es ein so weit verbreiteter Ansatz, dass es in ext4 selbst gepatcht wurde.
Wenn Ihre Verwendung also dem Muster entspricht, sollten Sie auf der sicheren Seite sein.
Wenn nicht, empfehle ich Ihnen, weiter nachzuforschen, anstatt fsync einzufügen hier und da, nur um sicher zu sein. Das ist seit fsync vielleicht keine so gute Idee mehr kann ein großer Performance-Hit auf ext3 sein (lesen).
Andererseits ist das Leeren vor dem Umbenennen der richtige Weg, um die Ersetzung auf Nicht-Journaling-Dateisystemen durchzuführen. Vielleicht hat ext4 deshalb dieses Verhalten zunächst von Programmen erwartet, die auto_da_alloc Option wurde später als Fix hinzugefügt. Auch dieser ext3-Patch für den Writeback-Modus (Non-Journaling) versucht, den unvorsichtigen Programmen zu helfen, indem er beim Umbenennen asynchron löscht, um die Wahrscheinlichkeit eines Datenverlusts zu verringern.
Hier können Sie mehr über das ext4-Problem lesen.