Hide Forgot
https://fedoraproject.org/wiki/Changes/BtrfsByDefault Summary: - Compression saves space, significantly reduces write amplification and therefore increases flash lifespan, and in some cases increases performance. - Desired but not a requirement of the change proposal. Options: - do this with a mount option '-o compress=zstd:1' - dilemma: it doesn't always lead to equal or better performance. On some systems and workloads write performance is slightly reduced. What about LZO? - do this with per directory XATTR - dilemma: the target directories don't exist at install time, depending on whether the installation is rsync, rpm, or unsquashfs based. - do the install with -o compress, set XATTR post-install - dilemma: the installed files won't have XATTR set, only new files inherit, do 'dnf update' files overwrite and not inherit the XATTR or are they new files and do inherit? Which directories? Some may be outside of the installer's scope. /usr /var/lib/flatpak ~/.local/share/flatpak /var/lib/containers/ ~/.local/share/containers/ ~/.var ~/.cache (Plausible this list should be reversed. While compressing ~/.cache may not save much space, it's likely hammered with more changes than other locations, hence more benefit in terms of reducing write amplification.)
Elaborate on the last option: do the install with mount-time compression, and then set an XATTR. Anaconda supports post-install drop-in scripts. Super easy would be 'chattr -R +c' on the target directories. That'll ensure new files inherit, but also that existing files if overwritten continue to be compressed. Problem is 'chattr +c' defaults to zlib. So either: A. Make chattr +c default to zstd B. Some script magic to effectively make 'btrfs property set' recursive, which allows setting the XATTR with an explicit algo
Do you have some simple benchmarks on compression in /usr? That seems like the low-hanging fruit for sure. Is there any reason to not do /var wholesale? I guess /var/cache/dnf is probably redundant, but on my system here /var/log compresses by 96.4%. Which is _kind of a lot_.
I'm so fussy about benchmarks, methodology and measurments. I definitely need a sanity check. Literally and figuratively. It probably is the territory of devel@, let folks pick it apart bit by bit, because the details do matter. This is system specific, and lzbench gives a good way of showing relative benchmarks (comparison to different algorithms and levels), on a selectable payload. Such as a tar file of /usr, or whatever. /var might contain things other than VMs and databases we don't want compressed, but I'm not offhand thinking of anything.
bcl points out in bug 1860720#c3 that the installer already supports the first option -> do this with a mount option '-o compress=zstd:1' via kickstart '--fsoptions FSOPTS' This would mount the file system with compress=zstd:1 and add it to /etc/fstab. That's OK, but I think we want more control going forward, for example: - non-ISO "raw.xz" images are better off made as plain raw images using e.g. zstd:7 or higher. We're making Btrfs sysroot images for the ARM desktop spins. - in case of the third option -> do the install with -o compress, set XATTR post-install; we only want to use the mount option at install time, not added to fstab
continuing from Description -> Options. I've got a 4th option. - do the install with -o compress, set a NOCOMPRESS flag on /home post-install, i.e. 1. '--fsoptions compress=zstd:1' in the kickstart, to compress the installation and add it to fstab 2. %post install script 'btrf property set -ti /mnt/sysimage/home compression none' all files and folders in /home will inherit the NOCOMPRESS flag. Gotcha? New subvolumes don't get NOCOMPRESS. Compression will resume.
Removing from Btrfs by default for Fedora 33 tracking bug. We'll plan to do this in Fedora 34.
Consolidating btrfs issues for design and planning logics. This issue is now found here: #5 enable compression on btrfs installs https://pagure.io/fedora-btrfs/project/issue/5