" the question 'are these exact bits irrevocably committed to the media?' is pretty much impossible to answer" Well, kind of. fsync()'s job is only to ensure c

" the question 'are these exact bits irrevocably committed to the media?' is pretty much impossible to answer" Well, kind of. fsync()'s job is only to ensure caches are written to durable storage. Its job is not to ensure the integrity of durable storage. Your idea of fsync()'s "Right Thing" is not quite correct, because these types of durable storage failures can happen outside of the context of a write -- so it's a bit silly to point a finger at fsync(). For example, you can write bytes to disk today and the drive might experience corruption on that sector next week. "(and even then, I would not bet my life on it)" All hardware fails, so of course you shouldn't bet your life on it. That's why we have both onsite and offsite backups. The durable media itself can always fail and lose data -- even if there aren't any writes occurring. Data loss can even occur on a powered off system. Again, fsync()'s job is only to ensure the data is moved to durable storage. Solving the problem of data loss is done in other ways -- for example raid5 addresses the problem of durable storage failing by using parity and extra copies. The real takeaway from the blog is perhaps that Raft as a protocol is inadequate, in the same way a raid1 mirror system is inadequate in terms of protecting from data corruption on durable storage (which of the two mirrored drives has the correct version of the data?). I'm frankly surprised that this situation is undetectable. It's a solved problem in other storage layers. "I'll probably stick to SQLite write-ahead logs, at least I can wrap my mind around those" Well, keep in mind: those have the same problem in the event of durable storage failure.