fsync Reliability Issues
Cluster focuses on discussions about fsync's behavior across OSes, particularly how it may not guarantee data durability due to lying caches, filesystem options, drive controllers, and related bugs or workarounds like NCQ and write barriers.
Activity Over Time
Top Contributors
Keywords
Sample Comments
fsync on most OSes lie to some degree
Not sure, but there are references to proven incidents of fsync bugs in the docs. If you get that wrong, it is not hard to believe that the buffer cache could be wrong too.
Do you mean on Linux that calling fsync might not actually flush to the drive?
Also, the weird `fsync` behaviors is not part of it?
Related:The secret life of fsync - https://news.ycombinator.com/item?id=35399818 - April 2023 (62 comments)
Isn’t that only because they cheat and make fsync an noop though?
If the drive controllers don't lie about fsync, then maybe?
I didn't realise fsync syncs the whole fs. This explains some write cache issues I've been having writing real-time data streams to sometimes slow SD cards. This change would solve my problems rather than create problems. But hey now I can fix it anyway
FSYNC is not enough. You also have to make sure that NCQ is disabled:https://en.wikipedia.org/wiki/Native_Command_Queuing
Hopefully there’s an fsync as well.