Comment by nh2 | Hacker News Reader

Comment by nh2 | Hacker News Reader

Parent Full thread

That is also the most important part to me. But I don't understand it. It says:

> 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?

> > 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?

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.

It "works" in the sense that if nothing goes wrong you get the expected result. But you can omit the fsyncs and it still "works" to this standard.

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.

Does this answer my question?

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".

Sorry, you're right. fsync will report failure nowadays so you're not getting silent corruption.

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.

Reply on news.ycombinator.com