[catblast01]

It has some features that zfs lacks such as a dedup story that is actually usable, plus more flexibility in reshaping. Other than its native raid 5/6 story what major features is it lacking in comparison to zfs? I agree the tooling is trash compared to zfs (zfs command line is a delight by comparison). Also stability wise i haven’t noted problems in years. Not to take anything away from zfs which has proven itself in its particular use cases, but btrfs is alright.

[yjftsjthsd-h]

> Also stability wise i haven’t noted problems in years.

Counter anecdote: I have a laptop (single disk) running opensuse tumbleweed with root on btrfs, and it's managed to completely break its root filesystem twice. One of those times I tried to recover it, but in the end I just reinstalled.

[KozmoNau7]

Not that I know the exact hardware and circumstances, but in my experience that sounds like a hardware issue, either a buggy controller or a failing disk.

Zfs -with it's similar checksumming and integrity features- would likely have faced similar issues.

[yjftsjthsd-h]

It happened months apart and I never saw it report data errors. It could still be hardware, of course (I haven't tried to run ZFS on the same hardware), but even if it was a hardware fault this isn't an impressive failure mode. Like... what are the odds that a random hardware bug breaks BTRFS metadata in such a way that I can't even mount the filesystem, and never just breaks random files such that I get an isolated read error?

[jhoechtl]

I had such issues like 5 years ago. Since then no issue with a btrfs root fs.

[ac29]

Agreed, btrfs has been stable for a long time, aside from RAID5/6, which are going to be uncommon on a laptop or desktop computer. Unfortunately, 10 years ago this was definitely not the case, and btrfs hasnt been able to shake off that reputation among some people since then.

[loeg]

> Other than its native raid 5/6 story what major features is it lacking in comparison to zfs?

For example, native at-rest encryption. dm-crypt/luks is adequate, but has significant performance problems[0] on many-core hardware with highly concurrent storage (NVMe) due to excessive queuing and serialization. You can work around these things by editing /etc/crypttab and maybe sysctls.conf, but the default is pretty broken.

[0]: https://blog.cloudflare.com/speeding-up-linux-disk-encryptio...

[chungy]

Per-dataset properties, including different compression policies, exec/noexec, setuid/nosetuid, case-sensitivity, volumes, and snapshots that actually make sense.