Hacker News Reader

Comment by conradev | Hacker News Reader

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/

Is there a performance hit for f_fullfsync?

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

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.

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

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.

Would it not be possible to achieve this with something akin to how libeatmydata can be LD_PRELOAD-ed?

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

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.

Reply on news.ycombinator.com