4 ms·
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
by buckminster 6y ago
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.
- nh2 6y agoDoes 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".
- buckminster 6y agoSorry, 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.