Si vous ne vous souciez que d'ext4 et non d'ext3, je vous recommande d'utiliser fsync sur le nouveau fichier avant de renommer. Les performances de fsync sur ext4 semblent être bien meilleures que sur ext3 sans les très longs délais. Ou c'est peut-être le fait que l'écriture différée est le mode par défaut (du moins sur mon système Linux).
Si vous vous souciez seulement que le fichier soit complet et non quel fichier est nommé dans le répertoire, vous n'avez qu'à fsync le nouveau fichier. Il n'est pas non plus nécessaire de fsynchroniser le répertoire car il pointera soit vers le nouveau fichier avec ses données complètes, soit vers l'ancien fichier.
Non.
Regardez libeatmydata, et cette présentation :
Eat My Data :comment tout le monde se trompe en matière d'E/S de fichiers
http://www.oscon.com/oscon2008/public/schedule/detail/3172
par Stewart Smith de MySql.
Au cas où il serait hors ligne/plus disponible, j'en garde une copie :
- La vidéo ici
- Les diapositives de présentation (version en ligne des diapositives)
À partir de la documentation ext4 :
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.
A en juger par le libellé "applications cassées", c'est définitivement considéré comme une mauvaise pratique par les développeurs ext4, mais en pratique, c'est une approche si largement utilisée qu'elle a été corrigée dans ext4 lui-même.
Donc, si votre utilisation correspond au modèle, vous devriez être en sécurité.
Sinon, je vous suggère d'approfondir vos recherches au lieu d'insérer fsync ici et là juste pour être en sécurité. Ce n'est peut-être pas une si bonne idée depuis fsync peut être un impact majeur sur les performances sur ext3 (lecture).
D'un autre côté, le vidage avant le renommage est la bonne façon d'effectuer le remplacement sur les systèmes de fichiers non journalisés. C'est peut-être pourquoi ext4 s'attendait au début à ce comportement des programmes, le auto_da_alloc l'option a été ajoutée plus tard en tant que correctif. De plus, ce correctif ext3 pour le mode d'écriture différée (sans journalisation) tente d'aider les programmes négligents en vidant de manière asynchrone lors du changement de nom afin de réduire les risques de perte de données.
Vous pouvez en savoir plus sur le problème ext4 ici.