The reason I ask is because the topic of
set-default-subvolume is being revisited in Debian. So to be clear, the
"[an]other system" was also Debian? I'd also sincerely appreciate it if
you would share your rationale for why you tried it, as well as why you
stopped using it.
Yes — it was Debian also.
Long time ago I thought, that "set-default-subvolume" is a great
feature. I can make many subvolumes, snapshots, and one special
subvolume is marked as default, and when system is booted
then this special subvolume becomes root.
My current /etc/fstab looks like:
UUID=ea6ae51d-d9b0-4628-a8f3-3406e1dc59c6 / btrfs
noatime,degraded,compress=zstd,subvol=/orion
UUID=ea6ae51d-d9b0-4628-a8f3-3406e1dc59c6 /mnt/root btrfs
noatime,degraded,compress=zstd,subvol=/,noauto
When I set /orion as default subvolume I can make fstab as simple as it
used in old times for ext3:
UUID=ea6ae51d-d9b0-4628-a8f3-3406e1dc59c6 / btrfs
noatime,degraded,compress=zstd
UUID=ea6ae51d-d9b0-4628-a8f3-3406e1dc59c6 /mnt/root btrfs
noatime,degraded,compress=zstd,subvol=/,noauto
But this is dangerous!
For example when you run scripts from my first post in this thread,
script changes default subvolume.
It is unnnoticable — until you try to delete subvolumes.
Btrfs complains "you can't delete default subvolume".
If I would boot my server, then it will get stuck on boot process.
So — the better solution is not to play with set-default-subvolume.
Better if everything is explicit, always explicit:
UUID=ea6ae51d-d9b0-4628-a8f3-3406e1dc59c6 / btrfs
noatime,degraded,compress=zstd,subvol=/orion
UUID=ea6ae51d-d9b0-4628-a8f3-3406e1dc59c6 /mnt/root btrfs
noatime,degraded,compress=zstd,subvol=/,noauto
#ls /mnt/root/ -1
orion
orion_snaps
# ls /mnt/root/orion
bin boot czytaj dev etc home lib lib64 media mnt opt proc
root run sbin snap spec srv sys tmp usr var
# ls /mnt/root/orion_snaps -1
'2024-08-31 23:46:01 298933885'
'2024-09-30 23:58:03 066051689'
'2024-10-31 23:54:01 844345165'
'2024-11-30 23:51:02 286451952'
'2024-12-31 23:53:01 812712611'
'2025-01-31 23:54:02 262220931'
'2025-02-28 23:51:03 390687865'
'2025-03-12 23:58:02 570605762'
'2025-03-18 23:53:02 817283280'
'2025-03-24 23:50:03 096441769'
'2025-03-31 23:58:03 590689111'
'2025-04-06 23:59:02 195100197'
'2025-04-12 23:55:01 925146759'
'2025-04-18 23:50:02 753467144'
'2025-04-20 23:52:02 365647389'
'2025-04-21 23:55:02 160780071'
'2025-04-22 23:55:01 853546455'
'2025-04-23 23:58:01 892381039'
'2025-04-24 23:55:02 034121916'
'2025-04-25 23:50:02 199518022'
Another example — how to boot btrfs filesystem from grub command line?
grub> root=(hd1,gpt2)
grub> ls ($root)/
orion_snaps/ orion/
grub> probe --fs-uuid ($root) --set myid
grub> echo $myid
0fac09ad-a5fd-4b43-b0bf-08d91655e3d8
grub> linux /orion/boot/vmlinuz-5.10.0-25-amd64 root=UUID=$myid
rootflags=subvol=orion
grub> initrd /orion/boot/initrd-img-5.10.0-25-amd64
grub> boot
subvol=orion is important.
Don't rely on 'set-default". :) :)
So my advice for newbie in Btrfs would be: forget about default subvolume.
You subvolumes A and B were not in a relationship with subvolume C,
so this was "user error".
To be fair, did you find that the documentation for "clones" was
insufficient? It could be argued that an optimistic reading of the
btrfs-progs docs would lead a user to suppose something like "oh neat!
If I mark a bunch of subvolumes as clones then the kernel will figure
everything out automatically, deduplicate, and only send the diff". If
that's the case then it's an upstream documentation bug!
I have search many, many times "what is the difference between -p and -c
option".
I have never found any good example how to use it.
Maybe whole this bug is from my misunderstanding between -p and -c options.
Why to use -c when you have -p?
How could be "btrfs send -p -c -c ... | ssh .. btrfs receive"
better then the same command without -c?
