One Apple platforms, you also want to use F_FULLFSYNC instead of fsync if you need durability:

https://www.sqlite.org/pragma.html#pragma_checkpoint_fullfsy...

If Apple compiled your SQLite library, not even the fullfsync PRAGMAs will do F_FULLFSYNC. Apple has “secretly” patched their SQLite to do F_BARRIERFSYNC instead.

https://bonsaidb.io/blog/acid-on-apple/

▲

baruz 4 days ago | parent | prev [-]

Is there a performance hit for f_fullfsync?

▲

mananaysiempre 4 days ago | parent [-]

Yes, that’s why those systems can cheat on benchmarks by defaulting to half-arsed fsync() in the first place.

▲

londons_explore 4 days ago | parent [-]

Half arsed fsync is all I want.

I am happy to lose 5 or 10 seconds of data in a power failure. However I'm not okay with a file becoming so corrupted that it is unmountable when the power recovers.

Half arsed fsync provides exactly that - and considering you get way more performance this seems like a good tradeoff.

▲

Avamander 4 days ago | parent | next [-]

Fsync is also overused at times, like some random web app's local storage does not need to be forced onto the disk.

▲

londons_explore 4 days ago | parent [-]

That fsync behaviour I think is a good part of the reason that apps seem to run faster/better on osx than windows/Linux.

I wish Linux and windows would have settings to change all fsyncs to barriers too.

Unfortunately I think Linux recently removed such an ability on the basis the code complexity wasn't worth it.

	▲	Avamander 4 days ago \| parent [-]
		Would it not be possible to achieve this with something akin to how libeatmydata can be LD_PRELOAD-ed?

▲

conradev 4 days ago | parent | prev [-]

You don’t need fsync at all for that, just WAL. fsync is only half arsed on Apple platforms.

	▲	mxey 3 days ago \| parent [-]
		You need write barriers for the ordering guarantees of a WAL. that’s why Apple uses barrier sync and not full sync. AFAIK other operating systems do not have this distinction.