Dans son post, il explique que c'est une utilisation très courante que de passer par de petits fichiers par exemple pour les configurations. Et d'ajouter qu'on est d'accord pour perdre une modification, mais pas pour mettre toute sa conf en vrac.
Le problème lié à ext4 c'est que les le filesystem ne garantie pas que les modifications seront faite dans l'ordre où elles ont été appelées. Donc le rename peut survenir avant le write() en pratique car les modifications sur les données sont gérées séparément des modifications sur la table des inodes de ce que j'ai pu comprendre. En faisant son rename() à la fin (le rename doit être atomique, en tout cas on n'a pas une fenêtre d'ouverture de 50 secondes) on se dit que si tous le reste a été effectué, alors seulement on fera le rename(), si un plantage a eu lieu avant d'arriver au rename(), on aura au pire un fichier en trop sur le filesystem mais on aura gardé l'ancienne configuration.
[^] # Re: Le post de Matthew Garett est aussi très intéressant
Posté par Étienne . En réponse au journal Don’t fear the fsync!. Évalué à 5.
Le problème lié à ext4 c'est que les le filesystem ne garantie pas que les modifications seront faite dans l'ordre où elles ont été appelées. Donc le rename peut survenir avant le write() en pratique car les modifications sur les données sont gérées séparément des modifications sur la table des inodes de ce que j'ai pu comprendre. En faisant son rename() à la fin (le rename doit être atomique, en tout cas on n'a pas une fenêtre d'ouverture de 50 secondes) on se dit que si tous le reste a été effectué, alors seulement on fera le rename(), si un plantage a eu lieu avant d'arriver au rename(), on aura au pire un fichier en trop sur le filesystem mais on aura gardé l'ancienne configuration.