What does HackerNews think of libeatmydata?

libeatmydata - because fsync() should be a no-op

Language: C

Bcachefs – A New COW Filesystem | May 2023
Expand Context ↕
You can also add journal_async_commit,noauto_da_alloc

> maybe disable flushes with https://github.com/stewartsmith/libeatmydata

overlayfs has a volatile mount option that has that effect. So stacking a volatile overlayfs with the upper and lower on the same ext4 could provide that behavior even for applications that can't be intercepted with LD_PRELOAD
The secret life of fsync | Apr 2023
Expand Context ↕
oh well if you want ZFS to ignore the fsync calls... you could disable sync and rely on txg_timeout (default 5s) to write your state to disk.

Not recommended, but this is one of the things I tried (I tuned it to 1s to be slightly safer):

https://vadosware.io/post/everything-ive-seen-on-optimizing-...

But you probably want to be very sure that your desktop applications are somewhat safe with their data/can recover from crashes...

TIL of libeatmydata[0], if you're comfortable using that, you'd probably be comfortable disabling fsync on the datasets for those apps.

[0]: https://github.com/stewartsmith/libeatmydata
M1 Mac owners are experiencing high SSD writes over short periods of time | Feb 2021
Expand Context ↕
I "recommend" https://github.com/stewartsmith/libeatmydata :)
LD_PRELOAD: The Hero We Need and Deserve | Feb 2019
One useful tool for the toolbox, to be used very carefully, after thinking about the consequences:

libeatmydata: https://github.com/stewartsmith/libeatmydata

It disables fsync, o_sync etc, making them no-ops, essentially making the programs writes unsafe. Very dangerous. But very useful when you're trying to bulk load data in to a MySQL database, say as preparation of a new slave (followed by manual sync commands, and very careful checksumming of tables before trusting what happened)