CODEWITHSUNDEEP
dockermountdocker-volumemount-pointbtrfs
Christopher Shroba
Christopher Shroba

Reputation: 7584

Why don't mounted btrfs subvolumes show up in findmnt?

It appears that Docker creates btrfs subvolumes for its volumes. One example is:

ID 266 gen 116089 top level 256 path var/lib/docker/btrfs/subvolumes/166cda8dab21861bcae5e3186d5e21014278d311d68966af9778cecdbdc7a736

These show up when I run btrfs subvolume list /, but they aren't present in the output of findmnt (specifically findmnt -t btrfs). However, the grandparent (var/lib/docker/btrfs) directory of those subvolumes does show up in findmnt, and not in btrfs subvolume list /.

Why do all the docker subvolumes now show up in findmnt, and why does var/lib/docker/btrfs not show up in btrfs subvolume list /? I have a feeling I have a mistaken understanding of what subvolumes and mounts are. What am I missing?

(root@Denali) ➜  ~ btrfs subvolume list /
ID 256 gen 118049 top level 5 path @
ID 257 gen 118037 top level 5 path @home
ID 258 gen 118049 top level 5 path @log
ID 259 gen 116815 top level 5 path @pkg
ID 260 gen 116089 top level 5 path @.snapshots
ID 261 gen 116089 top level 256 path var/lib/portables
ID 262 gen 116089 top level 256 path var/lib/machines
ID 263 gen 116089 top level 256 path var/lib/docker/btrfs/subvolumes/c88814cb59930de002334e7a94f94bf50aa360fb1e8107e150debfd36a5e5376
ID 266 gen 116089 top level 256 path var/lib/docker/btrfs/subvolumes/166cda8dab21861bcae5e3186d5e21014278d311d68966af9778cecdbdc7a736
ID 267 gen 116089 top level 256 path var/lib/docker/btrfs/subvolumes/60b91a1d377c9e5590db43ef1b144070fa018921b12ca98b4c7685acc64a8901
ID 268 gen 116089 top level 256 path var/lib/docker/btrfs/subvolumes/856804c1243bc19f8514c021412b68ede0cdcb4ca88e45b647cabbba45ce471d
ID 269 gen 116089 top level 256 path var/lib/docker/btrfs/subvolumes/6dc9e1a16703c240cd8419d3c650954463d4cc0ef183fd0cedfc40cf896b0114-init
ID 270 gen 116089 top level 256 path var/lib/docker/btrfs/subvolumes/6dc9e1a16703c240cd8419d3c650954463d4cc0ef183fd0cedfc40cf896b0114
ID 277 gen 111108 top level 260 path @.snapshots/home/snapshot_2022.08.04T22.34.55
(root@Denali) ➜  ~ findmnt -t btrfs
TARGET                  SOURCE                                  FSTYPE OPTIONS
/                       /dev/sda2[/@]                           btrfs  rw,relatime,ssd,space_cache=v2,subvolid=256,subvol=/@
├─/var/cache/pacman/pkg /dev/sda2[/@pkg]                        btrfs  rw,relatime,ssd,space_cache=v2,subvolid=259,subvol=/@pkg
├─/.snapshots           /dev/sda2[/@.snapshots]                 btrfs  rw,relatime,ssd,space_cache=v2,subvolid=260,subvol=/@.snapshots
├─/home                 /dev/sda2[/@home]                       btrfs  rw,relatime,ssd,space_cache=v2,subvolid=257,subvol=/@home
├─/var/log              /dev/sda2[/@log]                        btrfs  rw,relatime,ssd,space_cache=v2,subvolid=258,subvol=/@log
├─/var/lib/docker/btrfs /dev/sda2[/@/var/lib/docker/btrfs]      btrfs  rw,relatime,ssd,space_cache=v2,subvolid=256,subvol=/@
└─/mnt/wd5tb            /dev/mapper/wd5tb_my_vg-wd5tb_my_vg_lv1 btrfs  rw,relatime,space_cache=v2,subvolid=5,subvol=/
(root@Denali) ➜  ~ findmnt | grep docker
├─/var/lib/docker/btrfs                                                                                                              /dev/sda2[/@/var/lib/docker/btrfs]      btrfs       rw,relatime,ssd,space_cache=v2,subvolid=256,subvol=/@
(root@Denali) ➜  ~

Upvotes: 1

Views: 381

Answers (1)

jbk
jbk

Reputation: 11

Being a geriatric noob, this is going to be a bit long-winded...

Some history: In the dark ages long ago, a disk device did not have partitions; all it then had was a 'volume label' as its third block of data. So, when the idea of a filesystem identifier arose, the 'volume label' was considered to be the 'file name'.

Then disk partitioning came along, and each partition could have its own filesystem. How could old compiled code cope? Simple - just leave the file name 'null' (the partition number will sort things out).

Thus it came that when you mount a 'filesystem' to a 'mountpoint', the 'mountpoint' was set to point at the top ('null') directory of the filesystem. (In the rare occasion when it was important to identify this directory, you will see <FS_TREE> shown instead of nothing.)

It didn't take long before EVERYTHING had a 'label' and a 'UUID, some usually 'null'.

Then came along the btrfs subvolume; a quasi btrfs filesystem under a higher (quasi?) btrfs filesystem. Oh, my! (To make things worse, even the btrfs filesystem 'top-level' is itself a subvolume, subvolid=5.)

Is it any wonder that Ubuntu jumped on the train to declare that the subvolume to which the 'root' directory (/) would be mounted must be @? (Personally, I extended this to a) EVERY subvolume starts with @; b) EVERY mountpoint for a subvolume ends with @; c) except for snapshots, subvolumes exist ONLY in the top-level subvol=5. I have ONE btrfs filesystem with multiple distro subvolumes and a common USER data extension subvolume. With a tiny script, I snapshot all the subvolumes in a single 3-second run. Sending copies of the new snapshots to the backup btrfs filesystem takes longer, but that runs in background.)

In short, the 'file name' is rarely set; occasionally this omission is flagged <FS_TREE>.

Upvotes: 1

Related Questions