Preparing for BTRFS

First freeze for Debian Bookworm (current testing) is January 12th 2023, meaning that the next release of Debian stable will happen mid-2023. I figured this is a good time to prepare for the upgrade.

At the same time I’m not very happy with my partitioning scheme, a Frankenstein, which doesn’t even look like one anymore. It is a result of having a single Debian Stable upgraded over and over since late Debian Jessie. It works flawlessly, but you can tell its age.

I have 4 partitions: /, /boot, /home and /storage. The last one occupies a whole second SSD which I installed 2 years ago. Root partition is constantly filled in 87%, leaving ~5 GB of free disk space. Meanwhile my /home is filled in 52% (91 GB free) and /storage is filled in 33% (147 GB free).

This setup was cool 5-6 years ago, but in recent years we have seen a boom of third-party package managers like Flatpaks, nix, and guix which use a lot of space on a root partition. Docker also places a lot of data on the root partition. Having a small root and a big /home doesn’t make sense anymore in 2022.

This led me to the conclusion that I should “regress” to the simple “One Big Filesystem”. Separate /home is great when you’re distro-hopping, but I never did that. Once I settled on Debian, I did it for life - I don’t have neither time nor patience to learn quirks of a new distribution.

Because I’ll need to repartition my entire filesystem (and restore it from backup), I figured that maybe this is a time for a change of FS itself to something more modern than ext4.

Ext4 has served me well for 15 years I think. But 2 years ago I have discovered BTRFS which I’m using on my home server. I immediately loved its snapshot and Copy on Write features and I think I’m going to have a good use of them when I finally upgrade my laptop. BTRFS also implements data compression and is able to span over separate hard drives (so good bye to /storage, which will screw my symlinks and make restoring of backup a little harder, but at least I’ll get rid of this hackery).

I thought that it’s a good idea to familiarize myself with some pitfalls of BTRFS so I dedicated yesterday’s evening for reading. So I read… and read… and read… and I made notes… and read and made even more notes.

I’ve never felt the urge to learn more about FS, but maybe it’s because I have used FS which didn’t have any significant features which would require my interaction. Like, the biggest features of ext4 were journaling, lack of data fragmentation and its stability. Yet with BTRFS there are so many things you must know. Like: use zstd algorithm for compression, which has better support than lzo, or make subvolumes for directories which you don’t want to include in snapshots, or don’t use RAID5/6, or forget about ordinary df, which will lie to you, or don’t use discard and autodefrag mount options, or don’t use a swap file, or remember that Debian installer doesn’t support creating BTRFS subvolumes…

Maybe it’s a fair price to pay for the features of BTRFS, but it is a little overwhelming for a newcomer.