Durability also requires the file system implementation and the disk to do the right thing on fsync, which, if I recall past discussions correctly, isn’t a given.

▲

ericbarrett 4 days ago | parent | next [-]

There are some older fsync() bugs (as famously explored by Postgres developers: 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 :)

▲

vlovich123 4 days ago | parent | next [-]

O_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.

	▲	4 days ago \| parent [-]
		[deleted]

▲

jitl 4 days ago | parent | prev | next [-]

macOS is a popular OS that has a fast and loose relationship to that syscall without F_FULLFSYNC

▲

codys 4 days ago | parent | prev | next [-]

Nothing 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 4 days ago | parent | prev [-]

Technically I think you need O_SYNC. O_DIRECT does pretty much the same but its intention is different.

▲

eatonphil 4 days ago | parent | prev [-]

Take a look at Alex Miller's diagrams for what function calls are actually doing on various systems.

https://transactional.blog/how-to-learn/disk-io