Hacker News new | ask | show | jobs
by marcodiego 1710 days ago
AFAIK, both btrfs and zfs are still slower than ext4 for most desktop use cases.
2 comments

Checksums and snapshots are so valuable I don't care about the performance impact. Modern file systems use more medatada so I expect them to be slower in metadata intensive operations, and the COW approach isn't good for every workload.
Depends. ZFS mirrors are very snappy.

Single disks were never a recommended option for ZFS, it's a filesystem designed for arrays.

> Single disks were never a recommended option for ZFS, it's a filesystem designed for arrays.

Not quite true IMHO. One of best features of ZFS is checksumming to ensure data integrity, where errors can be corrected if you have enough redundancy.

You certainly lose this feature with single disks, but you're not necessarily worse off than any other file system.

What ZFS gives you on a single disk is very convenient snapshots and very convenient (incremental) streaming of those snapshots to another system (via either a push or pull mechanism). Doing this with other file systems generally entail a lot more work and much less efficiency. btrfs can do it, but if you're using ext4, then you'll probably use rsync which has to walk the file tree to find changed files.

Also with ZFS and snapshots you can turn them into clones: writable copies. This allow boot environments were updates/upgrades can be done, and if things do not work out, you can boot back to the original setup:

* https://mwl.io/archives/2363

* https://vermaden.wordpress.com/2021/02/23/upgrade-freebsd-wi...

Probably even more crucial, setting compression=on is very likely to make ZFS performance even better than ext4, even on a single disk.
This and encryption seem mutually exclusive (for me with OpenZFS @ Ubuntu 21.04).
They occur at different layers:

> OpenZFS native encryption splits the difference: it operates atop the normal ZFS storage layers and therefore doesn't nerf ZFS' own integrity guarantees. But it also doesn't interfere with ZFS compression—data is compressed prior to being saved to an encrypted dataset or zvol.

* https://arstechnica.com/gadgets/2021/06/a-quick-start-guide-...

No, they are not. Compression happens on the plaintext data, and encryption applies post-compression.
From using ZFS since ~2008, I have only ever lost one ZFS pool, and it was due to lack of scrubs (the array was created on a FreeBSD version before ZFS was integral to the installer, and despite upgrades the nightly scripts just never got overwritten, so the array was never scrubbed).

I can't say I've never lost an ext4 partition either, but I've never lost one under normal use without some sort of weird hardware issue causing data corruption.

By definition, without a redundant copy of the data the scrub can't fix anything.

> Creating a pool with no redundancy is not recommended...

https://docs.oracle.com/cd/E26502_01/html/E36219/storage-4.h...

You can also have datasets on a single disk where copies can be set to 2 or more so that checksum errors can be recovered. Each dataset in zfs can have a wealth of options such as compression that are specific to them.