C'est pas pcq la norme POSIX n'interdit pas de faire des choses idiotes qu'il _faut_ faire de telles choses idiotes.
Un rename() étant une opération atomique, cela n'a quasiment aucun sens de ne pas garantir que le pattern open() write() close() rename() soit atomique quant à la transition entre les anciennes données et les nouvelles, et ce même en cas de crash. J'ose imaginer que les disques courants (ATA, SATA, SCSI, ...) ont des mécanisme de commandes de barrières qui permettrait d'apporter "facilement" de telles garanties - si ce n'est pas le cas il est urgent que leur comités normalisateurs respectifs se penchent sur le sujet....
fsync() est beaucoup plus fort qu'une simple barrière. L'utiliser dans tous les cas serait désastreux. C'est étonnant que ça ne paraisse pas évident à un kernel hacker.
[^] # Re: Le post de Matthew Garett est aussi très intéressant
Posté par Guillaume Knispel . En réponse au journal Don’t fear the fsync!. Évalué à 2.
Un rename() étant une opération atomique, cela n'a quasiment aucun sens de ne pas garantir que le pattern open() write() close() rename() soit atomique quant à la transition entre les anciennes données et les nouvelles, et ce même en cas de crash. J'ose imaginer que les disques courants (ATA, SATA, SCSI, ...) ont des mécanisme de commandes de barrières qui permettrait d'apporter "facilement" de telles garanties - si ce n'est pas le cas il est urgent que leur comités normalisateurs respectifs se penchent sur le sujet....
fsync() est beaucoup plus fort qu'une simple barrière. L'utiliser dans tous les cas serait désastreux. C'est étonnant que ça ne paraisse pas évident à un kernel hacker.