Bcachefs Brings Self-Healing Work & Better Reflink Repair For Linux 6.13

[muncrief]

A) Bcachefs is the most interesting file system from a news point of view. ZFS will never get upstream, btrfs will never not be a meme, XFS is old and lacks many features etc. Bcachefs is the only legitimately interesting filesystem, and one of the few actually interesting and relevant bits of news for a larger audience

B) it always gets good engagement

I found btrfs to be incredibly slow, and bcachefs far to immature to be relied upon.

So I run CachyOS as it provides integrated OpenZFS support as well as optimized kernels and packages. It's the most feature complete and error free distro I've used in the decades I've been running Linux.

[mdedetrich]

Yeah idk guys... all these people defending it with their lives but there's just something about a filesystem that's been in development for 9 years and still can't remove the "experimental" label and which no other experienced filesystem developers are willing to touch with a 100ft pole that just does not inspire confidence in me.

Sorry to break it to you, but good filesystems that are actually hardy and resilient actually require a decade to develop. So in other words, it being experimental this long is a good thing, because just as Kent has stated he will not remove that label until its bcachefs is battle hardened and tested in every way possible.

This is much better than what happened with btrfs, which was premeturely put into the kernel without proper testing where it has earned its meme worthy status.

[Quackdoc]

I found btrfs to be incredibly slow, and bcachefs far to immature to be relied upon.

So I run CachyOS as it provides integrated OpenZFS support as well as optimized kernels and packages. It's the most feature complete and error free distro I've used in the decades I've been running Linux.

Personally I am using bcachefs for data that I really care about, but don't care about having 24/7 accsess to, I am also using it on all of my laptops/tablets because I don't really need super reliability out of them either anymore. It's been quite nice, I have had a few times where I boot up a device or mount it and nothing works, but I never once actually lost any data, nor felt like I did, bcachefs has been extremely impressive in this regard.

[muncrief]

Personally I am using bcachefs for data that I really care about, but don't care about having 24/7 accsess to, I am also using it on all of my laptops/tablets because I don't really need super reliability out of them either anymore. It's been quite nice, I have had a few times where I boot up a device or mount it and nothing works, but I never once actually lost any data, nor felt like I did, bcachefs has been extremely impressive in this regard.

That's good to hear Quackdoc. I understand that any file system is complex, and COW file systems are among the most so. Hopefully bcachefs will continue to progress and in a few years or so attain the reliability of its competitors. As even though I'm not a fan of its mercurial author, that doesn't bias me against his work. And if it results in a better, faster, and more reliable file system it will greatly contribute to the progress of Linux.

[gotar]

[extent tree v2] It's going.

Any commits backing this statement up? Last time I've checked it was stalled (for years). I'd be really glad if these issues were about to be addressed, as I do got some btrfs volumes in active use, some of them I cannot easily convert experiencing troubles.

Why is this even a counterargument to the "btrfs is not a meme" statement, how does absence of "extent v2" (assuming extent tree v2) makes btrfs "a meme"?

Because it is deficient by design. The on-disk format went public too soon and it's the source of many intrinsic problems.
They did implement some optional trees as an optimization technique (free space, block group), but in the meantime XFS gained refcount btrees and so the reflinks, reducing need for btrfs-likes in certain scenarios.

In btrfs, advanced defragmentation and deduplication algorithms are supposed to be implemented in userspace.

Yeah, I'm talking about the userspace, which is not even close to being "advanced". The kernel-part "advanced" RAID-1 reading technique for many years (in times of no 3-way mirroring) was "even/odd PID reads even/odd slice", userspace didn't progress a bit since then.

[no reliable quota] From which ass did you pull this?

From public discussions on linux-btrfs@, provoked by issues spotted in production.
That can easily be reproduced, so just go ahead and share your results, before you throw insults next time.
I can trash entire volume in a matter of hours, therefore I choose carefully which volumes might be handled and can benefit from btrfs according to usage-patterns and needs, but none of them is exposed publicly or in Internet-facing services.
This supports my claim about not being general-purpose fs, as I don't have to think about any of my EXT4/XFS servers in the wild. Oh, I still got one reiserfs server waiting to be replaced.

[missing encryption, checksum-awareness in regard to RAID1]
What does this even mean?

It means you're not using filesystems extensively enough to understand trivia.

But let me explain: checksummed-filesystem-level RAID1 has an advantage, that when discrepancy in data is found, it can automatically read the other copy.
Without encryption baked into filesystem, one has to encrypt all the data twice (or more - one time per each mirror) and put already encrypted volumes into btrfs RAID1.
Considering that crypto-authentication is checksumming itself, this is both redundant and inefficient.

Assuming we want to encrypt only once and still fail over detected errors, this is more performant:

dm-integrity - RAID1+ - dm-crypt - fs (whatever, can be one-way btrfs, can be ext3).

but other issues emerge, namely initialization of empty space (that needs to be encrypted) or support for discard. Both of them are relevant if the stack lays on top of thinly provisioned device, e.g.

LVM-thin -> integritysetup -> mdadm -> LUKS -> fs

because now we're basically wasting space, unless we enable discards (not enabled by default at LUKS, security considerations).
But if we do TRIM and already have thin snapshots, this stack simply outperforms btrfs.

I do have some btrfs RAID1 over LUKS and this is PITA - I have to unlock all the components separately, before partially-activated btrfs goes into degraded mode.
In headless machines this is simply not reliable enough to be production ready.

This is why it's important to have encryption layer above RAID above checksumming.

This is why bcachefs providing encryption is such a deal.


Some stats from my fresh server, having clean setup (no legacy volumes):

$ lsblk | grep btrfs | wc -l
4
$ lsblk | grep xfs | wc -l
2
$ lsblk | grep ext4 | wc -l
25
$ lsblk | grep lvm | wc -l
139
$ lsblk | grep crypt | wc -l
32
$ lsblk | grep raid1 | wc -l
22

There would be two more btrfses if it had encryption (both will be XFS/LUKS/MD/integrity/LVM).

And let's not forget - comparing to btrfs which lacks per-subvolume profiles, the more similar setup is also much simpler one:
integrity -> RAID1 -> LVM -> LUKS or
integrity -> RAID1 -> LUKS -> LVM (if everything is to be encrypted and can use common key).


If the bcachefs was ready today, having reflinks, encryption, multidevice, checksumming, CoW and snapshots - it covers 95% of my needs.
The remaining are send/receive, which eventually will happen.