Looks good. I have a little bit of feedback:
need about 20-50% of free disk space
I think it’s reasonable to say they’ll want 20%, or more, free. In reality, it’s a tiny amount of metadata, maybe 4% of the reported used space is what’s typically needed. But that would sound like it’s OK to try to convert a 95% full file system. It might work.
What about LVM?
I think this section is good as it is. There are a number of ways to merge the two, perhaps a future article though. One idea I have is converting both / and /home LV’s to btrfs. Snapshotting / and then using btrfs send/receive to sent it to the home LV (or in the other direction if the free space assessment works out better). This would build on the previous btrfs send/receive article in Fedora Magazine.
Free up disk space
Considering VM images as top candidates for removal. They take up lots of space, which is good for the conversion process to use. And they will need to be recopied anyway, because convert will make them COW, and we need to make them nodatacow. This isn’t automaticaly done with btrfs-convert.
- Inside root subvolume, delete home folder.
Delete the contents of the home directory, because the home subvolume will need this empty home directory in the root subvolume as a mount point.
An alternative for handling the home subvolume, instead of creating a snapshot and cleaning it up:
btrfs subvolume create home2
cp -a home/* home2/
rm -rf home
mv home2 home
New in Fedora 33, cp now uses reflink copies by default. So this will do a fairly fast lightweight copy from the old home directory to the new home subvolume. The end result is the same either way.
Modify fstab
- Consider removing the 2nd paragraph entirely, and recommend the user run
blkid to get the UUID for the Btrfs file system. This is valid whether MBR or GPT partition scheme is used, it’s a UUID for the file system itself, and it will be repeated twice. Once for the / entry and again for the /home entry, only differing by the subvolume mount option.
- For LVM installations, typically UUID is not used, but the name of the VG/LV.
- I suggest only the single option
subvol=root and subvol=home. That’s what a default installation will produce. And then the article doesn’t need to suggest using a different defragment target size to account for compression.
Chroot into your system
Looks like we need to umount the Btrfs from /mnt first. Then mount in order:
mount -o subvol=root /dev/vda3 /mnt
mount /dev/vda2 /mnt/boot
mount /dev/vda1 /mnt/boot/efi
Otherwise subsequent commands won’t work.
Reinstall GRUB, regenerate initramfs
Pretty sure the only thing required here is grub2-mkconfig with -o option pointed to the correct location. The btrfs driver is now built into the kernel.
After first boot
# btrfs balance start / <- this can take several hours
No need for a full balance. The man page only suggests balancing metadata, using -m option. So either:
btrfs balance start -m /
or
btrfs balance start -mconvert=dup /
btrfs-convert by default creates a single copy of metadata, whereas mkfs.btrfs uses single for SSD and dup for HDD. Strictly speaking it looks in sysfs for whether it’s considered rotational, if so, it uses dup metadata.
Finally, the VM images:
chattr +C on the containing directory, e.g.
chattr +C /var/lib/libvirt/images
Copy them back or duplicate them in place with cp and delete the original. Confirm VM images are nodatacow with lsattr
New clean installs will have this configured automatically when the storage pool is first activated.
It is definitely not obvious, and also suboptimal but chances are cross mount point copies are somewhat rare.