Why ZFS Is Cool

The central argument is that many applications need fsync to preserve write ordering, but not necessarily to guarantee that every acknowledged write survives a power loss. On the author’s ext4 system, each fsync could force a journal commit and flush both mirrored disks’ caches, making even a tiny write wait behind substantial background I/O. In tests, log writes took about 30 ms at the median and as long as 4.1 seconds during a large write; fsyncs also slowed that write by 40%. Raising ext4’s journal interval did not avoid these flushes. User-space batching either falsely acknowledged unsaved data or left applications waiting, while disabling fsync outright could break ordering and corrupt databases.

The author instead moved the homelab to ZFS with sync=disabled. ZFS writes copy-on-write transaction groups in sequence, publishing each completed group through an uberblock; after a crash, the pool remains consistent but may lose the latest tens of seconds of changes. That tradeoff suits this system, whose replaceable state can tolerate rollback, but mail and git retain normal synchronous behavior because acknowledged messages and commits matter. After the switch, disk utilization fell from 13% to 2.7%, average write latency from 16 ms to 2 ms, and read latency from 16 ms to 7 ms. The setup also assigns datasets and record sizes to different workloads, uses compression and HDD-friendly metadata options, and takes snapshots so live services can be backed up consistently without stopping them.