Btrfs nested subvolume, is this... normal? [SOLVED]

Hey guys, the question is : Can I safely delete the btrfs subvolume (id 267) ?

check this out :

r:~$ sudo btrfs subvolume list /
ID 265 gen 245943 top level 5 path home
ID 266 gen 245943 top level 5 path var/lib/machines
ID 267 gen 245715 top level 266 path var/lib/machines

267 is nested into 266, and findmnt -t btrfs -o TARGET,SOURCE,FSTYPE,OPTIONS showed me that 267 wasn’t mounted anywhere… so I am wondering if I could just delete it or if this is something there for a specific reason…

Personally, I could not find the reason behind it, but hey, I’m neither an expert, neither a member of the team, so… here I am, asking :slightly_smiling_face:

edit : hmmm… isn’t it part of the update strategy ? (in which case I might delete it no problem), it should be recreated when needed)

Investigation - summary :

  • 267 is nested into 266
  • 267 isn’t mounted anywhere
  • 267 isn’t a snapshot
  • 267 was created the same night

Inverstigation - longer version :

I must say that after borching my previous install stupidely, I took advantage of the situation to re-structure my disks and all, I’ll spare you the details. Anyhow, I did a reinstall that was reusing the previous subvolume that was mounted as “/”, though at that time, /home was on an ext4 partition. It’s only post install I decided to adopt a different strategy which made more sense to have /home as a subvolume of the btrfs partition hosting the subvolume mounted as /, and so where I created the /home subvolume. This is the relevant history that could somehow explain why there is a nested var/lib/machines in var/lib/machines, which I have a hard time making sense of.

The following tells us this is not a snapshot :

r:~$ sudo mount -o subvolid=5 /dev/nvme2n1p3 /mnt/tmp
r:~$ sudo btrfs subvolume show /mnt/tmp
/
	Name: 			<FS_TREE>
	UUID: 			38be9ced-1b7a-4f3a-ab87-a63cc03183d6
	Parent UUID: 		-
	Received UUID: 		-
	Creation time: 		2024-12-16 18:27:31 +0100
	Subvolume ID: 		5
	Generation: 		238574
	Gen at creation: 	0
	Parent ID: 		0
	Top level ID: 		0
	Flags: 			-
	Send transid: 		0
	Send time: 		2024-12-16 18:27:31 +0100
	Receive transid: 	0
	Receive time: 		-
	Snapshot(s):
	Quota group:		n/a
r:~$ sudo btrfs subvolume show /mnt/tmp/var/lib/machines
var/lib/machines
	Name: 			machines
	UUID: 			4432949b-eee3-de49-ab18-84bcae3b0538
	Parent UUID: 		-
	Received UUID: 		-
	Creation time: 		2025-11-12 19:34:08 +0100
	Subvolume ID: 		266
	Generation: 		246039
	Gen at creation: 	238574
	Parent ID: 		5
	Top level ID: 		5
	Flags: 			-
	Send transid: 		0
	Send time: 		2025-11-12 19:34:08 +0100
	Receive transid: 	0
	Receive time: 		-
	Snapshot(s):
	Quota group:		n/a
r:~$ sudo btrfs subvolume show /mnt/tmp/var/lib/machines/var/lib/machines
var/lib/machines/var/lib/machines
	Name: 			machines
	UUID: 			df8b3c7b-7cc8-7d47-b02a-43d571dbe139
	Parent UUID: 		-
	Received UUID: 		-
	Creation time: 		2025-11-13 01:37:15 +0100
	Subvolume ID: 		267
	Generation: 		245715
	Gen at creation: 	238583
	Parent ID: 		266
	Top level ID: 		266
	Flags: 			-
	Send transid: 		0
	Send time: 		2025-11-13 01:37:15 +0100
	Receive transid: 	0
	Receive time: 		-
	Snapshot(s):
	Quota group:		n/a

No, it isn’t typical to have a var/lib/machines inside /var/lib/machines

It is probably a side effect of you re-using your subvolumes with different mount points.

If they’re empty, you can remove them. If nspawn wants them, it’ll recreate them.

Thanks guys, it is empty, I’ll delete it. :grinning_face: :+1:

nb: (267 is empty, 266 is my / so no deleting this one :grin: )