Btrfs Enjoys Performance Optimizations With Linux 6.9

[intelfx]

Do you have a theoretical understanding of how to do this, even if it is not practically implementable?

I do. What makes btrfs so bad for this type of workload is the combination of CoW and extents. Fix the extent size and "phase" (i. e. require all extents to start and end on a multiple of the extent size), add RMW to the slow path and you should be getting something very similar to ZFS' recordsize. Then if you align that with the RDBMS' page size (or virtualized disk block size), you should be getting all the benefits of CoW with little to no downsides.

Now, another issue is the scalability of the in-memory data structures (the oft-cited "holding locks while doing I/O"). That needs to be solved separately and is purely a quality of implementation issue.

[cynic]

is Btrfs still a serious project? I feel like it has been so completely eclipsed by ZFS and don't really know what it even offers over XFS or ext4.

1. yes, it's the most serious advanced FS in the linux kernel.
2. no, it's not eclipsed by ZFS.
3. there are tons of articles explaining the differences between btrfs and "traditional" filesystems.

[Rovano]

is Btrfs still a serious project? I feel like it has been so completely eclipsed by ZFS and don't really know what it even offers over XFS or ext4.

https://www.youtube.com/watch?v=KjmuBo8xoCU

[stiiixy]

I do. What makes btrfs so bad for this type of workload is the combination of CoW and extents. Fix the extent size and "phase" (i. e. require all extents to start and end on a multiple of the extent size), add RMW to the slow path and you should be getting something very similar to ZFS' recordsize. Then if you align that with the RDBMS' page size (or virtualized disk block size), you should be getting all the benefits of CoW with little to no downsides.

Now, another issue is the scalability of the in-memory data structures (the oft-cited "holding locks while doing I/O"). That needs to be solved separately and is purely a quality of implementation issue.

Do you have an article or 12 I could read up on this particular subject matter? I have a gap or three I feel I need to fill based on what you just said.

And I got nothing after 'I do' 👰🏿♂️

[fallingcats]

is Btrfs still a serious project? I feel like it has been so completely eclipsed by ZFS and don't really know what it even offers over XFS or ext4.

COW, snapshots, compression, checksums, and a raid-1 mode, that's superior to basically any other implementation, because you don't need to match disk sizes. You can throw any weirdly sized disks at it, as long as the largest one isn't larger than all the others you don't waste any storage.

And I'm saying that as a ZFS user.

[Nth_man]

is Btrfs still a serious project? I feel like it has been so completely eclipsed by ZFS and don't really know what it even offers over XFS or ext4.

Coder wrote: "BTRFS has all of the features I need, and it's a native (i.e. in-tree) filesystem. Also, it's the default filesystem used by some popular distros, making it probably the 2nd widest-used Linux filesystem, today. That translates into better support and reliability."
-- https://www.phoronix.com/forums/foru...65#post1261765

"Btrfs offers CoW snapshots, transparent file-system compression, SSD storage optimizations, native RAID capabilities, and a variety of other modern features not offered by EXT4. Some of the other benefits to Fedora that have been expressed include better low disk space handling, Btrfs' extensive checksumming, proper I/O isolation via cgroups2, online shrink/grow capabilities, and simpler setups of complex storage arrays".
-- https://www.phoronix.com/news/Fedora...esktop-Approve

[milo_hoffman]

Time for Red Hat to reconsider adding BTRFS into RHEL. They jumped the gun with RHEL7 and the had to back pedal quickly because it was not ready.

Now they are way behind with zero support of btrfs in RHEL.

[pWe00Iri3e7Z9lHOX2Qx]

Do you have a theoretical understanding of how to do this, even if it is not practically implementable? For me it's hard to see how COW could be made to compete with update-in-place.

You don't need to turn off COW in these situations with ZFS. And being able to tune the recordsize can make enormous differences in performance. I can get over 5 GB/s on a pair of cheap 4TB PCIe 3 NVMe drives in RAID 0 with heavy random writes like you'd see with a bunch of active VMs, with COW enabled along with native encryption and lz4 compression.

[Darksurf]

Time for Red Hat to reconsider adding BTRFS into RHEL. They jumped the gun with RHEL7 and the had to back pedal quickly because it was not ready.

Now they are way behind with zero support of btrfs in RHEL.

They started their own train wreck (Stratis) to "replace the need for BTRFS". Stratis is glue to make cobblestone garbage IMHO. https://stratis-storage.github.io/
BTRFS would be much better at achieving the same goals in a unified way.

[S.Pam]

It would be nicer to see btrfs gain some optimisations for running a vm/sql db on it, rather than having to disable CoW.

Well I don't disable cow and I use databases. The databases are not saturating IO so it's not a bug issue for me. There are things that can be done to improve the situation on the db side. For example large InnoDB page sizes if using mariadb/mysql and disabling double writes as those are completely unnecessary on cow filesystems.

I would like to see some mariadb cooperation with btrfs to tune their db engine even better. I think it could go a long way.