Re: Btrfs best practices
Hello! I think I should inform this list about my choices so far:
Em [2021-12-16 qui 14:13:05-0300], Jorge P. de Morais Neto escreveu:
> Should I use a backported kernel as Btrfs [wiki][] recommends? I worry
> that bullseye-backports comes from Debian testing with poor security.
I'm just using bullseye's kernel (5.10 LTS).
> For lifetime and space saving, I intend to install Debian to the SSD
> with compress-force=zstd:12, but then adopt compress-force=zstd. Thus
> the installation will be slow---I'll do something else while the
> installer works---but the installed system will be efficient, right?
I'm still using compress=zstd:12 and it's performing well. Notice I
went from "compress-force=zstd:12" to just "compress=zstd:12". That is
because of:
Using the forcing compression is not recommended, the heuristics are
supposed to decide that and compression algorithms internally detect
incompressible data too.[1]
Btrfs contains an internal heuristics that determines if some data
is compressible so that it doesn't try to compress data that isn't
compressible as this wastes CPU time. The compress-force mount
option bypasses this heuristics in order to gain better compression
ratios. A downside is that this increases fragmentation with
non-compressible files.[2]
1: https://btrfs.readthedocs.io/en/latest/Compression.html "Compression —
BTRFS documentation"
2: https://wiki.tnonline.net/w/Btrfs/Compression#The_compress-force_mount_option
"Btrfs/Compression - Forza's ramblings"
In the near future I intend to reduce this strong compression level (12)
to something more usual, in order to reduce power usage.
> Is fragmentation a concern? Is the [Gotchas][] article accurate?
I now have little to worry about fragmentation, because:
1. I dedicated a raw partition to my qemu-KVM virtual machine, bypassing
Btrfs.
2. I moved the caches of ungoogled-chromium, GNU IceCat, Firefox,
Evolution and GNU Guix to the HDD, because they (especially the web
browser caches) were writing too much temporary data to the SSD.
Thus, if they ever become too fragmented, I can now just defrag them,
without the danger of wearing the SSD.
3. I made a script to find heavily fragmented files (using compsize's
output) and so far I have nothing to worry about.
> ** Subvolumes
I read https://en.opensuse.org/SDB:BTRFS and laid out subvolumes
according to this fstab excerpt:
LABEL=SSD / btrfs noatime,space_cache=v2,compress=zstd:12,subvol=@rootfs 0 0
LABEL=SSD /var/cache btrfs noatime,space_cache=v2,compress=zstd:12,subvol=@var-cache 0 0
LABEL=SSD /var/backups btrfs noatime,space_cache=v2,compress=zstd:12,subvol=@var-backups 0 0
LABEL=SSD /var/mail btrfs noatime,space_cache=v2,compress=zstd:12,subvol=@var-mail 0 0
LABEL=SSD /var/spool btrfs noatime,space_cache=v2,compress=zstd:12,subvol=@var-spool 0 0
LABEL=SSD /var/tmp btrfs noatime,space_cache=v2,compress=zstd:12,subvol=@var-tmp 0 0
LABEL=HDD /var/log btrfs noatime,space_cache=v2,compress=zstd:12,subvol=@var-log 0 0
LABEL=SSD /var/lib/libvirt/images btrfs noatime,space_cache=v2,compress=zstd:12,subvol=@libvirt-images 0 0
LABEL=HDD /var/cache/apt/archives btrfs noatime,space_cache=v2,compress=zstd:12,subvol=@apt-archives 0 0
LABEL=HDD /root btrfs noatime,space_cache=v2,compress=zstd:12,subvol=@~root 0 0
LABEL=SSD /home btrfs noatime,space_cache=v2,compress=zstd:12,subvol=@home 0 0
LABEL=SSD /home/cache btrfs noatime,space_cache=v2,compress=zstd:12,subvol=@home-cache 0 0
LABEL=HDD /home-HDD btrfs noatime,space_cache=v2,compress=zstd:12,subvol=@home 0 0
LABEL=HDD /home-HDD/cache btrfs noatime,space_cache=v2,compress=zstd:12,subvol=@home-cache 0 0
LABEL=SSD /gnu btrfs noatime,space_cache=v2,compress=zstd:12,subvol=@guix-store 0 0
LABEL=SSD /var/guix btrfs noatime,space_cache=v2,compress=zstd:12,subvol=@guix-var 0 0
LABEL=SSD /usr/local btrfs noatime,space_cache=v2,compress=zstd:12,subvol=@usr-local 0 0
Rationale:
1. In the future I could snapshot @rootfs before certain system
operations (say, large upgrades). If I then rollback the system to a
snapshot, I'll still want the latest logs, user data, cache,
libvirt-images etc., so these should be outside the @rootfs
subvolume. Also, including them in snapshots would be very expensive
because some of these directories have too much variable data.
2. If I snapshot @home (probably for backup) I don't want to snapshot
user cache (see above).
3. Some user data should be on the HDD, such as videos, music, pictures,
downloads etc. They are large files that would fill the SSD; and
their usage characteristics don't require SSD performance.
4. Also some of the user cache should be on the HDD (such as web browser
caches), to avoid wearing the SSD.
> ** Swappiness
I have not messed with swappiness.
Speaking of swap, I dedicated a 16 GiB swap partition at the start of
the HDD.
All is working well, except for some error messages I get when shutting
down. See my email from Thu, 20 Jan 2022 08:57:35 -0300 with subject
'"Failed unmounting "/{root,var/cache} error messages when shutting down'
(Message-ID <[🔎] 87zgnq62mo.fsf@disroot.org>).
Kind regards,
Jorge
--
- Many people hate injustice but few check the facts; this causes more
injustice. Ask me about <https://stallmansupport.org>
- I am Brazilian. I hope my English is correct and I welcome feedback.
- https://www.defectivebydesign.org
- https://www.gnu.org
Reply to: