3 ms·
There are some older fsync() bugs (as famously explored by Postgres developers: https://wiki.postgresql.org/wiki/Fsync_Errors https://wiki.postgresql.org/wiki/F
by ericbarrett 1y ago
There are some older fsync() bugs (as famously explored by Postgres developers: https://wiki.postgresql.org/wiki/Fsync_Errors https://wiki.postgresql.org/wiki/Fsync_Errors ) but I'm not aware of any modern mainstream kernel where this is broken. If I'm wrong, please tell me!
An application that really wants confidence in a write—to the extent that the underlying device and drivers allow—should use O_DIRECT. Or maybe there is a modern equivalent with io-uring. But that is not easy engineering :)
- jitl 1y agomacOS is a popular OS that has a fast and loose relationship to that syscall without F_FULLFSYNC
- codys 1y agoNothing prevents using O_DIRECT as an open-flag for a fd used in other io_uring operations. But I'm not sure I'd necessarily think of O_DIRECT as a way of improving "confidence in a write". It's a way to get a specific behavior.
- geertj 1y agoTechnically I think you need O_SYNC. O_DIRECT does pretty much the same but its intention is different.
- vlovich123 1y agoO_DIRECT in now way absolves you from needing to call fsync because fsync ALSO sends a signal to the storage device to flush the buffer if it has anything which is important for durability. What OP is referring to is that some drives ignore that signal for performance reasons and there’s nothing SW can do to solve that part. io_uring in no way changes the rules here.
- deleted 1y ago[deleted]