Ask HN: Btrfs VS ZFS for Linux personal computer in 2022? | Hacker News Reader

Ask HN: Btrfs VS ZFS for Linux personal computer in 2022?

5 pointscapableweb7 comments

Which of these filesystems should I go with today if I want to ensure being able to recover from failures and also not have poor performance? Which one is most mature today? Which one doesn't require too many magical incantations to be able to recover files and do common maintenance?

In short: What filesystem of these should I go with today if I want to have the best and easiest user experience?

View on HN

Either will be fine, I tend to prefer btrfs on laptops (and desktops with consumer storage) for the ease of managing subvolumes/snapshots, the ability to use `cp --reflink=always` to clone big shit (git repos usually) instantly at (almost) no cost and the lower background drive wear.

Generally btrfs is friendlier to use but bugs and failures are messier — I haven't had btrfs blow up badly in years but I'd make a backup schedule and stick to it anyway. I have a btrbk job fire and sync my latest snapshots off my work laptop whenever I plug in my external backup drive, I'd recommend something similar if you value your data and time.

ZFS has been on my list of things I should learn "some day" for a long time. I installed Fedora a while ago and ended up opted into Btrfs without really trying. I have been pleasantly surprised with it and have used it on 2 low-impact servers and 3 personal computers for about a year.

I don't tend to do anything very interesting to tax the filesystem so it is most important that things just work day to day and the less maintenance the better. I found a few use cases[0] for the copy-on-write abilities of Btrfs (built into systemd-nspawn) after switching but even that was a case where something I was previously doing was made instantly faster rather than working out a btrfs incantation.

I've recently been trying out a nifty backup tool[1] to try out a snapshot feature locally. This one did require two btrfs specific commands to restore a backup (`btrfs {send,receive}`). Once again though, this was an additional feature I decided to try out and not really required for my day to day. For me personally Btrfs has been easy to adopt because of how low-friction it has been to add and learn incrementally.

I've still not learned ZFS.

[0]: https://idle.nprescott.com/2022/systemd-nspawn-and-btrfs.htm...

[1]: https://digint.ch/btrbk/

I use ZFS (4 x 2TB drivers in mirror mode = 4TB pool) for my backup system since 2014. I never had to "learn" anything ZFS related, the interface is fairly simple if you're familiar with CLI apps and the documentation for ZFS is crystal clear. The system overall is very easy to reason about. Works in a "set-and-forget" mode for me, every now and then I create, destroy or resize some volumes. I had to swap a broken HDD and re-silver once in 5 years it was two hours work IIRC.

Awesome, that’s the kind of experience I’m looking for. Some tutorials make it seem really complex and intimidating.

The main drawback you have to keep in mind is that you cannot modify pool size. Every pool can have one or more volumes. For advanced features like ARC caching, I'm just using sensible defaults.

Also, keep in mind that ZFS need at least 8GB of RAM, possibly 16GB for up to 16TB of data.

Wow, I was just searching HN with the same question with regards to a new server build. A lot of what I’ve seen in terms of discussion in the last few years ends with “ZFS is more complicated, but because Btrfs is still not as reliable as necessary, go with ZFS.” I’m wondering if this is still the consensus. Anyone with strong opinions one way or the other?

I have been using ZFS for a while. Simple, reliable and nice. I now run it even on my laptop and do ZFS send receive for backups.

The only limitation is that deduplication requires too much ram and cpu, and is therefore almost useless. Otherwise, I highlight recommended ZFS.

Btrfs doesn’t have native encryption, that’s already not good.

Reply on news.ycombinator.com