Fedora Workstation 34 Looking To Employ Btrfs Zstd Transparent Compression By Default

[dekernel]

For me, the use of BTRFS on my workstation is something I really avoid. For my builds, the times are very inconsistent (like 2 to 3 times as long), and my test databases will take FOREVER to load. The worst one is if I play with building indexes to tuning....YIKES. Yes, I am aware that the COW of BTRFS requires serious tuning, but it still doesn't seem to give me the same consistency and speed of EXT4. That is just my mileage so BTRFS on a true workstation seems to be just the wrong knife for the job.

[Slithery]

Tumbleweed installer defaults to a GPT with a BIOS BOOT Partition of 8 MiB, plenty space to bring in zstd support.

If that's true then it's a terrible decision, GPT BIOS booting is highly dependant on the motherboard vendor/model and is no way guaranteed to work.

The reason was for compatibility reasons, ie: people with MBR disks with no BIOS BOOT Partition.

MBR partitioned drives never need a BIOS boot partition as there is already spare room in the MBR to store the GRUB payload.

I have old PCs with BIOS from 2011 that can boot GPT disks without problems.

So do I. But as I said already you can't rely on that being the case.

EDIT: Didn't Arch made the same decision?

Arch doesn't have a default bootloader, you choose one that fits your requirements.

[skeevy420]

Interesting - do you have any sources/numbers that show it's better? And do you know about a bug report anywhere? Sounds like something that should get addressed.

It's in the man pages and discussed on Reddit.

[Yalok]

Wonder which fs is faster in disk benchmarks on fedora 33, ext4 or btrfs

[useless]

MBR partitioned drives never need a BIOS boot partition as there is already spare room in the MBR to store the GRUB payload.

It isn't? The whole issue came up since there's no room for the grub core image in the partition gap.

Arch doesn't have a default bootloader, you choose one that fits your requirements.

What other bootloader other than GRUB can you use with BIOS firmware that can boot a zstd compressed btrfs? In this scenario, your only choice is GRUB. And I recall reading that Arch also applied that same patch to disable zstd in the i386-pc GRUB target (I would like to be corrected tough).

[Zan Lynx]

If that's true then it's a terrible decision, GPT BIOS booting is highly dependant on the motherboard vendor/model and is no way guaranteed to work.

GPT UEFI booting IS guaranteed to work.

And in my opinion if you need to run Linux on hardware older than ten years, use a special distro for that. None of the main-line distros released in 2020 should worry about it.

[zxy_thf]

GPT UEFI booting IS guaranteed to work.

And in my opinion if you need to run Linux on hardware older than ten years, use a special distro for that. None of the main-line distros released in 2020 should worry about it.

Exactly. Even recent kernels are not aware of decade-old hardware

There are some effort on SLTS Linux kernel, aiming 30 years of support, but I'm afraid even the very first SLTS kernel (4.4) is too new for decades old hardware, nor to say a distribution.

[pal666]

"compress-force" makes BTRFS use Zstd's compression check algorithm when determining whether to compress a file or not and is more efficient than what BTRFS uses by default when just "compress" is used.

it's not better. it will just try to compress everything, i.e. it's a tradeoff between space savings and cpu costs

[zxy_thf]

it's not better. it will just try to compress everything, i.e. it's a tradeoff between space savings and cpu costs

Last time when I was reading this topic, the situation was:
This option does compress everything, but zstd is well optimized for incompressible data, while btrfs's heuristics simply suck.

If btrfs hasn't improved its algorithm to determine if to call the compression algorithm, the situation would be the same, i.e., it's better to compress everything and let zstd handle those incompressible cases.

[S.Pam]

I'm not a Fedora user so this is as good of a bug report as y'all are gonna get from me:

mount -o [B]compress[/B]=zstd:1

should be

mount -o [B]compress-force[/B]=zstd:1

"compress-force" makes BTRFS use Zstd's compression check algorithm when determining whether to compress a file or not and is more efficient than what BTRFS uses by default when just "compress" is used.

Indeed compress-force has its uses. One thing to remember is that it increases the amount of extents/blocks for files, which increases fragmentation.

The heuristics were bad, but was improved so I no longer recommend using it by default, but rather enable it on a use-case basis. For example on a backup filesystem.

I made a short writeup about btrfs compression a little while ago, if you're interested. https://wiki.tnonline.net/w/Btrfs/Compression