So I installed Debian 12 with btrfs and apparently it only uses a single subvolume rootfs
. I would like to have my /home
in a separate subvolume (and possibly /var
too I guess) and with a flat subvolume structure. I started figuring out on how to do it and I feel like I’m not entirely sure yet so I need a sanity check.
Lots of comments online seem to use something like this method:
cd /
mv /home /home_old
btrfs subvolume create home
cp -a --reflink=always /home_old/* /home/
But this would NOT create a flat subvolume structure, right? And you woul NOT need to modify fstab
as the /home
would be automatically mounted because it resides under rootfs
actually because /
is rootfs
and not its parent?
If I want to actually have a flat structure, then I would first need to mount the actual parent subvolume (subvolumeid=5), cd into it, then create the home
subvolume, copy everything from the current home
directory into there, unmount, modify fstab
to mount home
, and delete the old stuff and reboot I guess.
Soo something like this:
mkdir /mnt/tmp
Make a folder for mount
mount -o subvolid=5 /dev/sdXX /mnt/tmp/
Mount the actual parent subvolume
cd /mnt/tmp/
Here 'ls -a' would output 'rootfs' if I understood correctly
btrfs subvolume create home
Create new subvolume, now being sibling of 'rootfs'
cp -a --reflink=always /home/* /mnt/tmp/home/
Copy old /home
umount /mnt/tmp/
Don't need it anymore
Then go to fstab
, and do something like
...
UUID= / btrfs subvol=rootfs bunch_of_options_and_stuff
...
-> change into
...
UUID= / btrfs subvol=rootfs bunch_of_options_and_stuff
UUID= /home btrfs subvol=home bunch_of_options_and_stuff
...
Then just rm -rf /home/*
(or just move to keep it as backup if something is fucked up) and reboot?
Does this sound about right?
Edit:
Everything went smoothly. Well just don’t fuck up fstab like I did. Decided not to make /var
into a subvolume because not sure if you can do it the same way, thinking that logs etc are being written all the time so the gap between me copying everything to the subvolume, and eventually booting might make weird things but dunno. Also added compress=zstd
into fstab
mount options to reduce writes on the ssd.
Yes, that seems correct to me. I would also say that the flat layout is preferable because it makes dealing with snapshots later easier. When snapshotting the rootfs subvolume you won’t have to keep track of where exactly the home subvolume is located and it is easier to boot into a different rootfs snapshot.
Ignore this, I typed this tired and with misconceptions. Original left here for context.
I use automatic snapshots whenever the package manager installs/updates a batch of packages, so I’d hate to have to work with a flat layout.
Which system is best depends on your use case, but I would waste gigabytes of space if I were to snapshot my home directory during the daily package updates!
Could you just not include home in the automatic snapshots?
BTRFS snapshots are taken per subvolume. I have a root subvolume @ which I can let Timeshift snapshot all the time (storage is hundreds of megabytes per update, which allows for plenty of restore points) and an @home that’s exempt from automated snapshots.
I still don’t see how having a flat subvolume layout would make that more problematic. You can still (even better in my opinion) choose what subvolumes to automatically snapshot, which to include in backups etc.
I was under the impression that nested subvolumes get snapshotted together, but after thinking about it and looking up how nested subvolumes work, I was wrong:
What should be mentioned early is that a snapshotting is not recursive, so a subvolume or a snapshot is effectively a barrier and no files in the nested appear in the snapshot.
Apologies for my confusion.
This seems right and exactly the way I’ve set it up. On subvolid=5 I have subvolumes
and
@home
, in/etc/fstab
I mount/
assubvol=@
, and/home
assubvol=@home
.Okay good! Yes the @ seems to be more common and necessary for Timeshift, but I think I’ll just keep this and use Snapper or something.
rm -rf /home/*
You need the directory for the mount point.
Ah right yes, that makes sense. Edited.