Btrfs For Linux 6.6 Brings Fixes, Partially Recovers From Scrub Performance Regression

[phoronix]

Phoronix: Btrfs For Linux 6.6 Brings Fixes, Partially Recovers From Scrub Performance Regression

Btrfs in Linux 6.5 brought various performance improvements and prior to that it was a busy cycle with Linux 6.4 while now with Linux 6.6 the Btrfs file-system driver is mostly centered on delivering fixes...

https://www.phoronix.com/news/Btrfs-Linux-6.6

[pkese]

Does anyone have any information on how extent-tree-v2 is progressing?

I'm occasionally seeing Josef pushing some commits & refactorings to maling list, but I'm not familiar with the big picture.

[Steffo]

I'm curous about new performance benchmarks.

[Nth_man]

> the integrity checker tool is deprecated

"misguided attempts at starting a flame war.
Btrfs' integrity checker is nothing more than an internal debugging tool (that has outlived its usefulness). You are not supposed to use it if you are not actively debugging Btrfs code."
-- intelfx on https://www.phoronix.com/forums/foru...70#post1398370

[Azpegath]

I'm running BTRFS on 3 disks, my main NVMe disk with root and home on it, as well as 2 mirrored disks that have "all my stuff" that doesn't need to be on an NVMe disk.
Now I've discovered that all my file systems have faults, and I have to reformat them. The "btrfs check" tool has a repair command, but they really discourage users from ever using it.
I'm a bit disappointed. I thought I had gone for the most robust FS.

[skeevy420]

I'm a bit disappointed. I thought I had gone for the most robust FS.

Native, in-kernel, file systems without relying on external frameworks like Stratis, BTRFS is the most advanced there is. Ext4 and XFS are probably the most robust in regards to data safety while BTRFS is the most robust in regards to features.

In the next couple of years I'd expect Bcachefs to overtake everything in-kernel for both data safety and features on general file systems (nothing specialized like F2FS, tmpfs, NFS, etc).

If you extend it to included non-native Linux file systems, ZFS is the most robust and the one I consider to be the best. It'll be a long time before Bcachefs catches up to ZFS in regards to features and data safety. Granted, ZFS has 20+ years on Bcachefs and 6+ years on BTRFS so its devs have had a lot of time to find and fix edge cases and add nifty stuff...

[zexelon]

I'm running BTRFS on 3 disks, my main NVMe disk with root and home on it, as well as 2 mirrored disks that have "all my stuff" that doesn't need to be on an NVMe disk.
Now I've discovered that all my file systems have faults, and I have to reformat them. The "btrfs check" tool has a repair command, but they really discourage users from ever using it.
I'm a bit disappointed. I thought I had gone for the most robust FS.

Yeah... I ran BTRFS a couple of years ago on a test system and found it to be problematic... it didnt run long... Everything since then has been XFS on LVM and that has been rock solid stable but it does not have the full "feature set". If you wan the full feature set of BTRFS without the risk to everything you own and love (to put it bluntly) go with OpenZFS and stick with LTS kernels.

Just set up a server a week or so ago on OpenZFS with Ubuntu (xfs was still used for the root) and ZFS for all the data. The setup and operation of ZFS has so far been a breath of fresh air!

[user1]

Now I've discovered that all my file systems have faults, and I have to reformat them.

By "faults" you mean file system corruption?
Btw, have you ever experienced something like a power cut or an unclean shutdown / restart for whatever reason and as result it caused issues on btrfs?
Just curious because from reading various user's experiences with btrfs, it seems like a fairly common issue. Much more common at least compared to ext4.

[skeevy420]

By "faults" you mean file system corruption?
Btw, have you ever experienced something like a power cut or an unclean shutdown / restart for whatever reason and as result it caused issues on btrfs?
Just curious because from reading various user's experiences with btrfs, it seems like a fairly common issue. Much more common at least compared to ext4.

For me, that'd be yes. Up until 2018 I ran multiple disks with multiple distributions installed using different file systems just to try different things out on real hardware and I've lived in places with such great infrastructure that a 20mph+ wind would make the power flicker and, in those times, I had more issues losing random data with BTRFS than anything else. I've never used BTRFS for just a data disk; only root volumes that I wasn't afraid of losing data with. Before 2016 the data disk role went to XFS, 2016 and beyond its been ZFS.

Nowadays, I don't find the whole running 8 distributions thing very fun.

[fitzie]

Does anyone have any information on how extent-tree-v2 is progressing?

I'm occasionally seeing Josef pushing some commits & refactorings to maling list, but I'm not familiar with the big picture.

I think it's been abandoned for now. The branches are stale:

https://github.com/josefbacik/linux/branches

Block group tree was a big part of the original idea, and thats' been merged in linux for a while now (I'm a happy user of it). I don't think there was much buy in from other devs for the rest of extent v2. And there's plenty of work that will minimize contention without the partitioning that extentv2 would introduce so I think that's were all the effort has been spent. Maybe when that effort has been exhausted they'll look at this idea again.