Btrfs Sees Minor Performance Optimizations With Linux 6.12

[fong38]

Yeah , and this is kind of not what people expect. It only changes the property , it does not process the file at all (e.g. read/write everything) which is what you need to do if you want to change the compression method.

The current behavior is actually not that bad and far from insane , but it is not the behavior people expect.

I think they were referring to the actual compression level, meaning the number behind the compression algorithm to fine-tune the amount of compression applied. For instance zstd:6 or zlib:9. That only works with the fstab (force-)compress option.

[waxhead]

Surprisingly, method #4 cannot change compression level.

Yeah , and this is kind of not what people expect. It only changes the property , it does not process the file at all (e.g. read/write everything) which is what you need to do if you want to change the compression method.

The current behavior is actually not that bad and far from insane , but it is not the behavior people expect.

[gotar]

Actually BTRFS has 4 ways of setting compression

1. in fstab with the compress=zstd:level|lzo|zlib
2. with btrfs filesystem defrag -czstd object
3. with chattr +c object
4. with btrfs property set object compression zstd

That is way too many if you ask me, and I honesty think that only number 4 is the correct way of setting, changing or clearing the desired compression setting.

Surprisingly, method #4 cannot change compression level.

[ferry]

AFICT this is not actively worked on since years, unfortunately.

Also, this is not really that simple: you have to take in consideration when you have different profiles (RAID0, 1, C3, C4, 10) on mixed devices.
Moreover, there aren't only HDD and SDD in the storage world.

Sure, you can make it bigger. But there could be a minimal implementation, let's say, "single" on a hybrid of HDD and SSD. In that case the FS already needs to choose on which drive to place the file. How hard can it be to give a priority to the fastest drive.

Afaict there have been 3 different attempts, that got shot down. And then an excuse that it would be attempted via the VFS layer. A layered approach that lacks efficiency.

[cynic]

I'd really like to see btrfs finally implement the originally promised hybrid (SSD+HDD) hot relocate feature. How hard could it be? The driver on a multi-disk FS has to decide where to place a new file anyway (on the SSD), while files of low interest (no recent read/writes) could be moved away to the HDD.

AFICT this is not actively worked on since years, unfortunately.

Also, this is not really that simple: you have to take in consideration when you have different profiles (RAID0, 1, C3, C4, 10) on mixed devices.
Moreover, there aren't only HDD and SDD in the storage world.

[jacob]

Fedora switched to BTRFS by default in Fedora 33, which was in 2020 - that's 4 years now.
OpenSUSE did it even earlier than that - in January 2018 - that's 6 years ago.
I don't know what you are talking about.

ref. https://fedoramagazine.org/btrfs-coming-to-fedora-33/

Ubuntu doesn't use it by default, but offers it as an installation option and it's fully integrated (installation into subvolumes, etc).

[intelfx]

Actually BTRFS has 4 ways of setting compression

1. in fstab with the compress=zstd:level|lzo|zlib
2. with btrfs filesystem defrag -czstd object
3. with chattr +c object
4. with btrfs property set object compression zstd

That is way too many if you ask me, and I honesty think that only number 4 is the correct way of setting, changing or clearing the desired compression setting.
(And yes, I know that simply setting the property is not enough and you have to read/write to apply the compression)

You can actually set different compression algorithms on different objects such as /home /var/ /usr /here /there etc...
And I think you are incorrect that using option 3 disables COW on the file. +C disables COW , +c enables compression.

The GP is right in that all 4 of those methods are more or less shit. ZFS' properties are indeed better — more flexible, more coherent and more consistent than Btrfs' 10 half-assed ways of adjusting the filesystem behavior.

The good news is that the mechanisms are there (even more, the mechanisms are better than what ZFS has). Someone just needs to invent some actually good APIs and tooling to manipulate those mechanisms instead of the existing "made by Predators for Aliens" crap. I actually have some private patches to that end, but nobody will accept them in their current form, so they stay private (until I get some free time and energy on my hands). Perhaps I should start a Patreon page...

[waxhead]

It has piss poor compression compared to OpenZFS....

Actually BTRFS has 4 ways of setting compression

1. in fstab with the compress=zstd:level|lzo|zlib
2. with btrfs filesystem defrag -czstd object
3. with chattr +c object
4. with btrfs property set object compression zstd

That is way too many if you ask me, and I honesty think that only number 4 is the correct way of setting, changing or clearing the desired compression setting.
(And yes, I know that simply setting the property is not enough and you have to read/write to apply the compression)

You can actually set different compression algorithms on different objects such as /home /var/ /usr /here /there etc...
And I think you are incorrect that using option 3 disables COW on the file. +C disables COW , +c enables compression.

[avis]

<rant>
CoW filesystems are wrong
</rant>

You could drop the rant and explain why

Though personally I've never used one and continue to do so.

My FS history is quite stupid really:

FAT32 -> NTFS
ext2 -> ext3 -> dabbling with XFS for a short while, it was crap in the early 00s -> back to ext4.

[ferry]

I'd really like to see btrfs finally implement the originally promised hybrid (SSD+HDD) hot relocate feature. How hard could it be? The driver on a multi-disk FS has to decide where to place a new file anyway (on the SSD), while files of low interest (no recent read/writes) could be moved away to the HDD.