It's a bit weird that bcachefs is in the kernel, from what I understand there's still a lot of work to do on it. Would be nice to see more corporate sponsorship behind it, it's quite promising. Still not confident using it over ZFS.
My understanding was the majority of the work was performance tuning related. It's been explicit about still being in the "beta" phase. (See 3) https://bcachefs.org/FAQ/
The only way for it to get better was to get more and more users, merging it into mainline is the best place for that. The kernel maintainers also did put it through fire too, there was some heated exchanges that resulted in fixes before merging. https://www.phoronix.com/news/Bcachefs-Delayed-Linux-6.6
Its a bit weird that zfs isn't in the kernel, from what I understand the license is non GPL with a license chosen that directly prohibits its use in the kernel. Would be nice to see a license change, i'm heard its promising. I still wouldnt' use ZFS over ext4.
I've heard theories of how a license change could be possible but they all seemed more hope-based than reality-based.
I wouldn't let that keep you that from using ZFS though, it's an incredible battle-tested filesystem and features like native compression, encryption, and block-level backups make it an easy choice over ext4 for any of my systems.
btrfs has 1, 2 and 3, and if you count projects like WinBtrfs [0], then possibly 0 as well.
Been using it happily for years on my workstations, and about a year on my home server mainly because of the licensing issue and a kernel update possibly resulting in the ZFS pool not being imported.
ZFS is still great, but the kernel issue is still problematic on anything other than Ubuntu, where Canonical ships kernels with ZFS built right in.
Maybe the problem is me but I’ve never had a good time with mainline btrfs. I use it on a Synology without issue (they use a lot of patches and seemingly however use the built in RAID support.) but btrfs takes the cake for “unrecoverable errors from a filesystem” whenever I’ve used it for more than a “ext4++” filesystem on a single disk.
These features keeps me solidly without ZFS:
0. Powercut zfs host : cannot import pool without destroy old and create new.
1. For case "0" need minimum 2nd zfs host while backup restore even slower.
2. Extrem slow meta-/data reads with aging, eg try tar any dir to /dev/null.
3. So stay working with other alternatives and have fun.
Can you elaborate on the power cut data loss? I’ve never heard about that and I’m in the process of planning the addition of a ZFS pool to my home NAS.
I think it's unlikely to convince Linus and the myriad other contributors to change the license, but if you want to tilt at windmills, go ahead. A whole lot more likely than convincing Oracle.
I agree, the tone of my original statement was having fun with the wording. As cool as ZFS is, its not shipping with the kernel, so its not really acceptable to distributions with a commercial entity behind them.
Ubuntu (Canonical) ships with ZFS built-in as well as Proxmox and TrueNAS SCALE.
I doubt Red Hat / Fedora will ever ship it with how legally gunshy they were even before IBM, but there are many distros shipping it or have it an apt/pacman away.
Yes, without the auto-survive of a power outage zfs will never be accepted by redhat whatever the zfs license is look like in the future, still this simplest thing can bring lots of headache and pain even zfs designed zil and slog but what it's good for when you google cannot import pool ... ?!
You're wanting to take the drives out of a machine that lost power and import the pool somewhere else right? I've not done this, but the man page[1] for zpool-import shows -f and -F which would seem to address this use:
> -f Forces import, even if the pool appears to be potentially active.
> -F Recovery mode for a non-importable pool. Attempt to return the pool to an importable state by discarding the last few transactions. Not all damaged pools can be recovered by using this option. If successful, the data from the discarded transactions is irretrievably lost. This option is ignored if the pool is importable or already imported.
Do those not actually work? There's also zdb(8) if you want to debug a pool, which maybe is useful for recovery, but probably takes a lot of learning to actually be useful. I have about one unclean shutdown per zfs host every 3 years, when its ups battery has worn out and there's a utility power failure, and it's always come back up without intervention, but my write rate is very low.
It's been in the manpage since forever, this one dated 2006 also has -f (but not -F) [2]
Anytime the day will come where zpool options clear, -f, readonly, -F, -X, -T in any combination wouldn't help importing a pool. The best is to check that out by yourself by a power cut while writing to a testpool dataset and just be prepared for such a case. Theory and reality are two storys and not equal be design.
