Bcachefs Goes to "Externally Maintained"

(lwn.net)

Show context

betaby ◴[30 Aug 25 17:49 UTC] No.45076609[source]▶

The sad part, that despite the years of the development BTRS never reached the parity with ZFS. And yesterday's news "Josef Bacik who is a long-time Btrfs developer and active co-maintainer alongside David Sterba is leaving Meta. Additionally, he's also stepping back from Linux kernel development as his primary job." see https://www.phoronix.com/news/Josef-Bacik-Leaves-Meta

There is no 'modern' ZFS-like fs in Linux nowadays.

replies(4): >>45076793 #>>45076833 #>>45078150 #>>45080011 #

ofrzeta ◴[30 Aug 25 18:14 UTC] No.45076833[source]▶

>>45076609 #

Suse Linux Enterprise still uses Btrfs as the Root-FS, so it can't be that bad, right? What is Chris Mason actually doing these days? I did some googling and only found out that he was working on a tool called "rsched".

replies(4): >>45077496 #>>45078503 #>>45082115 #>>45089747 #

1. dmm ◴[30 Aug 25 19:50 UTC] No.45077496[source]▶

>>45076833 #

btrfs is fine for single disks or mirrors. In my experience, the main advantages of zfs over btrfs is that ZFS has production ready raid5/6 like parity modes and has much better performance for small sync writes, which are common for databases and hosting VM images.

replies(2): >>45078384 #>>45084324 #

2. riku_iki ◴[30 Aug 25 22:04 UTC] No.45078384[source]▶

>>45077496 (TP) #

> has much better performance for small sync writes

I spent some time researching this topic, and in all benchmarks I've seen and my personal tests btrfs is faster or much faster: https://www.reddit.com/r/zfs/comments/1i3yjpt/very_poor_perf...

replies(1): >>45083828 #

3. dmm ◴[31 Aug 25 15:17 UTC] No.45083828[source]▶

>>45078384 #

Thanks for sharing! I just setup a fs benchmark system and I'll run your fio command so we can compare results. I have a question about your fio args though. I think "--ioengine=sync" and "--iodepth=16" are incompatible, in the sense that iodepth will only be 1.

"Note that increasing iodepth beyond 1 will not affect synchronous ioengines"[1]

Is there a reason you used that ioengine as opposed to, for example, "libaio" with a "--direct=1" flag?

[1] https://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption-...

replies(1): >>45084006 #

4. riku_iki ◴[31 Aug 25 15:36 UTC] No.45084006{3}[source]▶

>>45083828 #

Intuition is that majority of software uses standard sync FS api..

5. m-p-3 ◴[31 Aug 25 16:16 UTC] No.45084324[source]▶

>>45077496 (TP) #

Context: I mostly dealt with RAID1 in a home NAS setup

A ZFS pool will remain available even in degraded mode, and correct me if I'm wrong but with BTRFS you mount the array through one of the volume that is part of the array and not the array itself.. so if that specific mounted volume happens to go down, the array becomes unavailable unmounted until you remount another available volume that is part of the array which isn't great for availability.

I thought about mitigating that by making an mdadm RAID1 formatted with BTRFS and mount the virtual volume instwad, but then you lose the ability to prevent bit rot, since BTRFS lose that visibility if it doesn't manage the array natively.

replies(1): >>45089592 #

6. wtallis ◴[01 Sep 25 04:57 UTC] No.45089592[source]▶

>>45084324 #

> with BTRFS you mount the array through one of the volume that is part of the array and not the array itself

I don't think btrfs has a concept of having only some subvolumes usable. Either you can mount the filesystem or you can't. What may have confused you is that you can mount a btrfs filesystem by referring to any individual block device that it uses, and the kernel will track down the others. But if the one device you have listed in /etc/fstab goes missing, you won't be able to mount the filesystem without fixing that issue. You can prevent the issue in the first place by identifying the filesystem by UUID instead of by an individual block device.

↑