I've been studying fsync() for a couple of years and I thought I'd seen every weird way that it could be used and misused, but this week I learned of one more that exists in the wild: if the program crashes between write() and fsync(), on restart, fsync() after open() to ensure those writes are on disk.
I am pretty sure this doesn't do what people think it does, and here's why:
https://despairlabs.com/blog/posts/2025-03-13-fsync-after-open-is-an-elaborate-no-op/
fsync() after open() is an elaborate no-op
I have spent the last couple of years of my life trying to make sense of fsync() and bringing OpenZFS up to code. I鈥檝e read a lot of horror stories about this apparently-simple syscall in that time, usually written by people who tried very hard to get it right but ended up losing data in different ways. I hesitate to say I enjoy reading these things, because they usually start with some catastrophic data loss situation and that鈥檚 just miserably unfair. At least, I think they鈥檙e important reads, and I鈥檓 always glad to see another story of fsync() done right, or done wrong.
despairlabs.com 路 despair labs
Link author: 
Rob 馃挌@robn@social.lol