Odd snapshot subvolume

Odd snapshot subvolume

[Brian J. Murrell]

On my Fedora system I have the following:

$ sudo btrfs subvolume show /
fedora_root
	Name: 			fedora_root
	UUID: 			c08a988c-ddd5-164e-b01e-51ac26bf018b
	Parent UUID: 		-
	Received UUID: 		-
	Creation time: 		2021-08-10 18:30:03 -0400
	Subvolume ID: 		258
	Generation: 		5029586
	Gen at creation: 	10
	Parent ID: 		5
	Top level ID: 		5
	Flags: 			-
	Send transid: 		0
	Send time: 		2021-08-10 18:30:03 -0400
	Receive transid: 	0
	Receive time: 		-
	Snapshot(s):
				fedora_root/previous-releases/f38_root
				fedora_root/previous-releases/f39_root
				fedora_root/previous-releases/f40_root.old
				fedora_root/previous-releases/f41_root
				previous-releases/f33_root
	Quota group:		n/a

All of the fedora_root/previous_releases/* snapshot subvolumes make
sense to me.  There are all accessible at:

$ ls -l /previous-releases/
total 0
dr-xr-xr-x. 1 root root 378 May 31  2023 f38_root
drwxr-xr-x. 1 root root 194 May 31  2023 f38_var
dr-xr-xr-x. 1 root root 378 Nov 11  2023 f39_root
drwxr-xr-x. 1 root root 194 Apr  1  2024 f39_var
dr-xr-xr-x. 1 root root 362 Jun 15  2024 f40_root.old
drwxr-xr-x. 1 root root 194 May 15  2024 f40_var.old
dr-xr-xr-x. 1 root root 362 Jun 15  2024 f41_root
drwxr-xr-x. 1 root root 194 May 15  2024 f41_var

But then there is that odd-duck snapshot "previous-releases/f33_root"
not under "fedora_root" and not showing under /previous-releases in the
filesystem's namespace.

How can I access that "previous-releases/f33_root" snapshot or even
just remove it?

Cheers,
b.

Re: Odd snapshot subvolume

[Andrei Borzenkov]

14.04.2025 17:34, Brian J. Murrell wrote:
> On my Fedora system I have the following:
> 
> $ sudo btrfs subvolume show /
> fedora_root
> 	Name: 			fedora_root
> 	UUID: 			c08a988c-ddd5-164e-b01e-51ac26bf018b
> 	Parent UUID: 		-
> 	Received UUID: 		-
> 	Creation time: 		2021-08-10 18:30:03 -0400
> 	Subvolume ID: 		258
> 	Generation: 		5029586
> 	Gen at creation: 	10
> 	Parent ID: 		5
> 	Top level ID: 		5
> 	Flags: 			-
> 	Send transid: 		0
> 	Send time: 		2021-08-10 18:30:03 -0400
> 	Receive transid: 	0
> 	Receive time: 		-
> 	Snapshot(s):
> 				fedora_root/previous-releases/f38_root
> 				fedora_root/previous-releases/f39_root
> 				fedora_root/previous-releases/f40_root.old
> 				fedora_root/previous-releases/f41_root
> 				previous-releases/f33_root
> 	Quota group:		n/a
> 
> All of the fedora_root/previous_releases/* snapshot subvolumes make
> sense to me.  There are all accessible at:
> 
> $ ls -l /previous-releases/
> total 0
> dr-xr-xr-x. 1 root root 378 May 31  2023 f38_root
> drwxr-xr-x. 1 root root 194 May 31  2023 f38_var
> dr-xr-xr-x. 1 root root 378 Nov 11  2023 f39_root
> drwxr-xr-x. 1 root root 194 Apr  1  2024 f39_var
> dr-xr-xr-x. 1 root root 362 Jun 15  2024 f40_root.old
> drwxr-xr-x. 1 root root 194 May 15  2024 f40_var.old
> dr-xr-xr-x. 1 root root 362 Jun 15  2024 f41_root
> drwxr-xr-x. 1 root root 194 May 15  2024 f41_var
> 
> But then there is that odd-duck snapshot "previous-releases/f33_root"
> not under "fedora_root" and not showing under /previous-releases in the
> filesystem's namespace.
> 
> How can I access that "previous-releases/f33_root" snapshot or even
> just remove it?
> 

mount -o subvol=/ /dev/whatever /mnt
ls /mnt/previous-releases

Re: Odd snapshot subvolume

[Brian J. Murrell]

On Mon, 2025-04-14 at 20:04 +0300, Andrei Borzenkov wrote:
> 
> 
> mount -o subvol=/ /dev/whatever /mnt
> ls /mnt/previous-releases

Ahhh.  Nice.

# mount -o subvol=/ /dev/mapper/rootvol--tmp-rootvol--0 /mnt/tmp

did the trick, thanks!

No clue what I did in the first place to get things in to such a mess,
but it's cleaned up now.  Thanks!

Cheers,
b.

Re: Odd snapshot subvolume

[Nicholas D Steeves]

[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]

Hi Brian,

"Brian J. Murrell" <brian@interlinx.bc.ca> writes:

> On my Fedora system I have the following:
>
> $ sudo btrfs subvolume show /
> fedora_root
> 	Name: 			fedora_root
> 	UUID: 			c08a988c-ddd5-164e-b01e-51ac26bf018b
> 	Parent UUID: 		-
> 	Received UUID: 		-
> 	Creation time: 		2021-08-10 18:30:03 -0400
> 	Subvolume ID: 		258
> 	Generation: 		5029586
> 	Gen at creation: 	10
> 	Parent ID: 		5
> 	Top level ID: 		5
> 	Flags: 			-
> 	Send transid: 		0
> 	Send time: 		2021-08-10 18:30:03 -0400
> 	Receive transid: 	0
> 	Receive time: 		-
> 	Snapshot(s):
> 				fedora_root/previous-releases/f38_root
> 				fedora_root/previous-releases/f39_root
> 				fedora_root/previous-releases/f40_root.old
> 				fedora_root/previous-releases/f41_root
> 				previous-releases/f33_root
> 	Quota group:		n/a
[snip]
> How can I access that "previous-releases/f33_root" snapshot or even
> just remove it?

  # mkdir -p /btrfs-admin
  # mount -o subvolid=5 /dev/disk/by-uuid/c08a988c-ddd5-164e-b01e-51ac26bf018b /btrfs-admin
  # cd /btrfs-admin
  # mv previous-releases/f33_root fedora_root/previous_releases/f33_root
  OR
  # btrfs subvolume delete /btrfs-admin/previous-releases/f33_root

To anyone else reading this:

Are there any reasons why distributions shouldn't set this up by
default?  What are the arguments against exposing the full structure in
/dev or in /sys (with permissions like 700)?

Regards,
Nicholas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]

P.S. Re: Odd snapshot subvolume

[Nicholas D Steeves]

[-- Attachment #1: Type: text/plain, Size: 323 bytes --]

P.S.

Nicholas D Steeves <sten@debian.org> writes:

>> just remove it?
>
>   # mkdir -p /btrfs-admin
>   # mount -o subvolid=5 /dev/disk/by-uuid/c08a988c-ddd5-164e-b01e-51ac26bf018b /btrfs-admin

Oops!  This /\ is wrong, because btrfs subvolume show / returns the
filesystem UUID, and the command above uses the disk UUID.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]

Re: P.S. Re: Odd snapshot subvolume

[Goffredo Baroncelli]

On 14/04/2025 19.24, Nicholas D Steeves wrote:
> P.S.
> 
> Nicholas D Steeves <sten@debian.org> writes:
> 
>>> just remove it?
>>
>>    # mkdir -p /btrfs-admin
>>    # mount -o subvolid=5 /dev/disk/by-uuid/c08a988c-ddd5-164e-b01e-51ac26bf018b /btrfs-admin
> 
> Oops!  This /\ is wrong, because btrfs subvolume show / returns the
> filesystem UUID, and the command above uses the disk UUID.

I have to correct you: "btrfs sub show" shows the *SUBVOLUME* uuid, where
/dev/disk/by-uuid/XXXX refers to the *FILESYSTEM* uuid.
Apart that, it is correct that you can't take the UUID from "btrfs sub show"
to mount a filesystem. You need the UUID from "btrfs fi show"

BR

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

Re: P.S. Re: Odd snapshot subvolume

[Nicholas D Steeves]

[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]

Goffredo Baroncelli <kreijack@libero.it> writes:

> On 14/04/2025 19.24, Nicholas D Steeves wrote:
>> P.S.
>> 
>> Nicholas D Steeves <sten@debian.org> writes:
>> 
>>>> just remove it?
>>>
>>>    # mkdir -p /btrfs-admin
>>>    # mount -o subvolid=5 /dev/disk/by-uuid/c08a988c-ddd5-164e-b01e-51ac26bf018b /btrfs-admin
>> 
>> Oops!  This /\ is wrong, because btrfs subvolume show / returns the
>> filesystem UUID, and the command above uses the disk UUID.
>
> I have to correct you: "btrfs sub show" shows the *SUBVOLUME* uuid, where
> /dev/disk/by-uuid/XXXX refers to the *FILESYSTEM* uuid.
> Apart that, it is correct that you can't take the UUID from "btrfs sub show"
> to mount a filesystem. You need the UUID from "btrfs fi show"

Of course 'subvolume show' gets subvolume UUID, 'filesystem show' gets
filesystem UUID, and this is too complicated.  Yes, it's logical, once
one understands btrfs, but multiple of my colleagues have looked at
stuff like this, thrown up their arms, and exclaimed things to the
effect of "I have more important things to think about".

To encourage btrfs adoption I think we need to do better.  After
considering alternatives, I wonder if there is anything simpler/better
than

  # findmnt -n -o SOURCE /foo | cut -d[ -f1

to get the device suitable for mounting -o subvolid=5 | subvol=/ ?  Ie:
"Just let me see everything with as little fuss as possible. Make it
simple!", without relying on fstab.

Cheers,
Nicholas


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]

Re: P.S. Re: Odd snapshot subvolume

[Goffredo Baroncelli]

On 14/04/2025 20.32, Nicholas D Steeves wrote:
> Of course 'subvolume show' gets subvolume UUID, 'filesystem show' gets
> filesystem UUID, and this is too complicated.  Yes, it's logical, once
> one understands btrfs, but multiple of my colleagues have looked at
> stuff like this, thrown up their arms, and exclaimed things to the
> effect of "I have more important things to think about".

:-)

> To encourage btrfs adoption I think we need to do better.  After
> considering alternatives, I wonder if there is anything simpler/better
> than
> 
>    # findmnt -n -o SOURCE /foo | cut -d[ -f1
> 
> to get the device suitable for mounting -o subvolid=5 | subvol=/ ?  Ie:
> "Just let me see everything with as little fuss as possible. Make it
> simple!", without relying on fstab.

Below a bit simpler command options set

     # findmnt -n -v -o SOURCE /foo

However I have to point out that this is not a specific BTRFS problem. See below

	ghigo@venice:/tmp/test$ mkdir t
	ghigo@venice:/tmp/test$ mkdir t2
	ghigo@venice:/tmp/test$ truncate -s 1G disk.img
	ghigo@venice:/tmp/test$ sudo losetup -f disk.img
	ghigo@venice:/tmp/test$ sudo mkfs.ext4 /dev/loop0
	ghigo@venice:/tmp/test$ sudo mount /dev/loop0 t/
	ghigo@venice:/tmp/test$ sudo touch t/a
	ghigo@venice:/tmp/test$ sudo mkdir t/b
	ghigo@venice:/tmp/test$ sudo touch t/b/c
	ghigo@venice:/tmp/test$ sudo mount -o X-mount.subdir=b /dev/loop0 t2

	ghigo@venice:/tmp/test$ ls t2/
	c

	ghigo@venice:/tmp/test$ findmnt t2/
	TARGET       SOURCE         FSTYPE OPTIONS
	/tmp/test/t2 /dev/loop0[/b] ext4   rw,relatime

	ghigo@venice:/tmp/test$ findmnt -n -o FSTYPE,SOURCE t2/
	ext4 /dev/loop0[/b]

For *any* filesystem, it is possible to mount a subdir of a filesystem as root.
BTRFS subvolume has some special properties (e.g. it is a "barrier" for the snapshot).
However the possibility to be mounted is not one of these BTRFS special properties.

If you want to know which subvolume is mounted, you have to look to the "subvol"
option in the mount command. However even a sub directory of a subvole can be mounted


	ghigo@venice:/tmp/test$ sudo mount -o X-mount.subdir=b,subvol=/subb /dev/loop1 t5
	ghigo@venice:/tmp/test$ findmnt t5
	TARGET       SOURCE              FSTYPE OPTIONS
	/tmp/test/t5 /dev/loop1[/subb/b] btrfs  rw,relatime,ssd,discard=async,space_cache=v2,subvolid=256,subvol=/subb

This to say that event for the common case "findmnt -n -v -o SOURCE <path>" may be
overkilling, there are some corner case where it is needed. To understand the situation I suggest to use

	ghigo@venice:/tmp/test$ findmnt -o FSTYPE,FSROOT,SOURCE -v t5
	FSTYPE FSROOT  SOURCE
	btrfs  /subb/b /dev/loop


> 
> Cheers,
> Nicholas
> 

Ciao
Goffredo

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

Re: P.S. Re: Odd snapshot subvolume

[Nicholas D Steeves]

[-- Attachment #1: Type: text/plain, Size: 2751 bytes --]

Hi Goffredo,

Goffredo Baroncelli <kreijack@inwind.it> writes:

> On 14/04/2025 20.32, Nicholas D Steeves wrote:
>> To encourage btrfs adoption I think we need to do better.  After
>> considering alternatives, I wonder if there is anything simpler/better
>> than
>> 
>>    # findmnt -n -o SOURCE /foo | cut -d[ -f1
>> 
>> to get the device suitable for mounting -o subvolid=5 | subvol=/ ?  Ie:
>> "Just let me see everything with as little fuss as possible. Make it
>> simple!", without relying on fstab.
>
> Below a bit simpler command options set
>
>      # findmnt -n -v -o SOURCE /foo

Oh, nice!  I guess it's been a while since I've read the fine manual.
Findmnt has a very, hmm...unique...definition of the "-v" option.

> However I have to point out that this is not a specific BTRFS problem. See below
>
[snip reproducer (see previous email)]
> 	ghigo@venice:/tmp/test$ sudo mount -o X-mount.subdir=b /dev/loop0 t2
>
> 	ghigo@venice:/tmp/test$ ls t2/
> 	c
>
> 	ghigo@venice:/tmp/test$ findmnt t2/
> 	TARGET       SOURCE         FSTYPE OPTIONS
> 	/tmp/test/t2 /dev/loop0[/b] ext4   rw,relatime
>
> 	ghigo@venice:/tmp/test$ findmnt -n -o FSTYPE,SOURCE t2/
> 	ext4 /dev/loop0[/b]
>
> For *any* filesystem, it is possible to mount a subdir of a filesystem as root.
> BTRFS subvolume has some special properties (e.g. it is a "barrier" for the snapshot).
> However the possibility to be mounted is not one of these BTRFS special properties.

Ouf, so the complexity has now become a generalised feature?

> If you want to know which subvolume is mounted, you have to look to the "subvol"
> option in the mount command. However even a sub directory of a subvole can be mounted
>
>
> 	ghigo@venice:/tmp/test$ sudo mount -o X-mount.subdir=b,subvol=/subb /dev/loop1 t5
> 	ghigo@venice:/tmp/test$ findmnt t5
> 	TARGET       SOURCE              FSTYPE OPTIONS
> 	/tmp/test/t5 /dev/loop1[/subb/b] btrfs  rw,relatime,ssd,discard=async,space_cache=v2,subvolid=256,subvol=/subb
>
> This to say that event for the common case "findmnt -n -v -o SOURCE <path>" may be
> overkilling, there are some corner case where it is needed. To understand the situation I suggest to use
>
> 	ghigo@venice:/tmp/test$ findmnt -o FSTYPE,FSROOT,SOURCE -v t5
> 	FSTYPE FSROOT  SOURCE
> 	btrfs  /subb/b /dev/loop

Why would someone do this, and what are the circumstances where it would
be required to spend resources engaging such complexity?  I honestly
feel like I'd be triggered into "nope, nope, nope, it's not a good use
of time to deal with this" if a team member did this!  That's one of the
reasons I want to document the simplest, overkilling, corner-case
mitigating workaround ;)

Thank you,
Nicholas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]

Re: P.S. Re: Odd snapshot subvolume

[Goffredo Baroncelli]

On 17/04/2025 23.22, Nicholas D Steeves wrote:
> Hi Goffredo,
> 
> Goffredo Baroncelli <kreijack@inwind.it> writes:
> 
>> On 14/04/2025 20.32, Nicholas D Steeves wrote:
>>> To encourage btrfs adoption I think we need to do better.  After
>>> considering alternatives, I wonder if there is anything simpler/better
>>> than
>>>
>>>     # findmnt -n -o SOURCE /foo | cut -d[ -f1
>>>
>>> to get the device suitable for mounting -o subvolid=5 | subvol=/ ?  Ie:
>>> "Just let me see everything with as little fuss as possible. Make it
>>> simple!", without relying on fstab.
>>
>> Below a bit simpler command options set
>>
>>       # findmnt -n -v -o SOURCE /foo
> 
> Oh, nice!  I guess it's been a while since I've read the fine manual.
> Findmnt has a very, hmm...unique...definition of the "-v" option.
> 
>> However I have to point out that this is not a specific BTRFS problem. See below
>>
> [snip reproducer (see previous email)]
>> 	ghigo@venice:/tmp/test$ sudo mount -o X-mount.subdir=b /dev/loop0 t2
>>
>> 	ghigo@venice:/tmp/test$ ls t2/
>> 	c
>>
>> 	ghigo@venice:/tmp/test$ findmnt t2/
>> 	TARGET       SOURCE         FSTYPE OPTIONS
>> 	/tmp/test/t2 /dev/loop0[/b] ext4   rw,relatime
>>
>> 	ghigo@venice:/tmp/test$ findmnt -n -o FSTYPE,SOURCE t2/
>> 	ext4 /dev/loop0[/b]
>>
>> For *any* filesystem, it is possible to mount a subdir of a filesystem as root.
>> BTRFS subvolume has some special properties (e.g. it is a "barrier" for the snapshot).
>> However the possibility to be mounted is not one of these BTRFS special properties.
> 
> Ouf, so the complexity has now become a generalised feature?
> 
>> If you want to know which subvolume is mounted, you have to look to the "subvol"
>> option in the mount command. However even a sub directory of a subvole can be mounted
>>
>>
>> 	ghigo@venice:/tmp/test$ sudo mount -o X-mount.subdir=b,subvol=/subb /dev/loop1 t5
>> 	ghigo@venice:/tmp/test$ findmnt t5
>> 	TARGET       SOURCE              FSTYPE OPTIONS
>> 	/tmp/test/t5 /dev/loop1[/subb/b] btrfs  rw,relatime,ssd,discard=async,space_cache=v2,subvolid=256,subvol=/subb
>>
>> This to say that event for the common case "findmnt -n -v -o SOURCE <path>" may be
>> overkilling, there are some corner case where it is needed. To understand the situation I suggest to use
>>
>> 	ghigo@venice:/tmp/test$ findmnt -o FSTYPE,FSROOT,SOURCE -v t5
>> 	FSTYPE FSROOT  SOURCE
>> 	btrfs  /subb/b /dev/loop
> 
> Why would someone do this, and what are the circumstances where it would
> be required to spend resources engaging such complexity? 

It allows to have multiple root. E.g. you can install different distro
on the same filesystem in different sub-directories. And you can mount
a directory as root easily passing X-mount.subdir.

Of course this flexibility, means that you now have to track not only:
- source device
- mount point

but also:

- source directory as root

If you think to this model, you can ignore the btrfs subvolume concept
entirely if you don't need the snapshots.

I have to point out that the root of this complexity/flexibility is in the possibility
to mount a path to another mount point. In fact if you do:

	# mount /dev/sda1 /path1
	# mount --bind /path1/subdir /mnt/other

you have

	# findmnt -o FSTYPE,FSROOT,SOURCE -v /mnt/other
	FSTYPE FSROOT  SOURCE
	ext4  /subdir  /dev/sda1

	(the example above was from my memory, so expect few typo)

And this is *not* filesystem dependent.

> I honestly
> feel like I'd be triggered into "nope, nope, nope, it's not a good use
> of time to deal with this" if a team member did this!  That's one of the
> reasons I want to document the simplest, overkilling, corner-case
> mitigating workaround ;)

If you don't use {mount --bind,mount -o X-mount.subdir, mount -o subvol=},
you can live as this complexity doesn't exist. If you want to mount a
"btrfs subvolume", you have to track this somewhere, and thus the
complexity.

> 
> Thank you,
> Nicholas

Ciao
Goffredo


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5