https://news.ycombinator.com/item?id=20509533
A temp file plus rename seems to be close but not fully enough.
This is exactly the sort of thing that should be abstracted by a standard library so that whatever needs to be done is correctly done.
> I was also (incorrectly) assuming that renaming a file after having fsynced the contents is a valid mechanism
Where does anyone say that this doesn't work?
I read the article twice and it suggests that open+write+fsync+close+dir-fsync is safe ("We've now seen what we have to do to write a file safely").
I've also read the reference "Bornholt et al., ASPLOS’16" mentioned in the "Rename" section; it says "One possible fix is to add an fsync(fd)". I cannot find another place in that paper that says otherwise. The later analysed Atomic-replace-via-rename (ARVR) and Atomic-create-via-rename (ACVR) approaches skip the fsync.
That said, user "tfha" replied to your linked thread
> I can confirm experimentally that the rename trick is not good enough.
but unfortunately without any data on whether the directory was fsynced, or on which file system.
So I'd like to ask again:
Is there any evidence that open+write+fsync+close+dir-fsync does not work?
> Where does anyone say that this doesn't work?
The article explains it here:
> This trick doesn't work. People seem to think that this is safe becaus the POSIX spec says that rename is atomic, but that only means rename is atomic with respect to normal operation, that doesn't mean it's atomic on crash. This isn't just a theoretical problem; if we look at mainstream Linux filesystems, most have at least one mode where rename isn't atomic on crash. Rename also isn't guaranteed to execute in program order, as people sometimes expect.
According to the article, open+write+fsync+close+dir-fsync is indeed safe on ext4 on any new-ish Linux kernel (on older kernels, fsync() wouldn't report errors in some cases, e.g. if it happened after the FS attempted and failed to write the data before the fsync).
Not sure what it has to do with rename though.
The article gives a concrete example of a failure mode: fsync can silently fail. If this happens then "open+write+fsync+close+dir+fsync" does not work.
Naturally I'm not talking about the "if nothing goes wrong case", but the power failure case, and thus obviously you shouldn't omit the fsyncs.
> fsync can silently fail
I don't think that's what the article says, nor do the linked references such as the LWN article about postgresql's "fsyncgate", where the problem is about re-opening files, and not re-doing writes when fsync returns failures.
In what I am talking about, and what "Bornholt et al., ASPLOS’16" are talking about, you do `fd = open(); write(fd); fsync(fd), close(fd)`, and I have not found any report of that silencing errors or not working as expected, except the linked HN comment by "tfha".
A different failure mode: the drive reorders writes and doesn't respect flush commands.
Edit: of course, you can't avoid the problem by changing the way you write the file. Files stored locally are inherently fragile.