Re: How to convert a directory to a subvolume

[John Center <jlcenter15@gmail.com>]

Hi Chris,

Thanks for responding!  Well, I made some progress:

root@Mariposa:/# mount /dev/sda3 /mnt

root@Mariposa:/# btrfs subvolume create /mnt/@opt
Create subvolume '/mnt/@opt'

root@Mariposa:/# btrfs subvolume list /
ID 256 gen 11732 top level 5 path @
ID 257 gen 11733 top level 5 path @home
ID 268 gen 11733 top level 5 path @opt

Once I unmounted /mnt, I had to create the /opt directory again:

root@Mariposa:/# umount /mnt

root@Mariposa:/# mkdir opt

Then I mounted /opt & it didn't complain:

root@Mariposa:/# mount /opt
root@Mariposa:/# btrfs subvolume list /
ID 256 gen 11751 top level 5 path @
ID 257 gen 11751 top level 5 path @home
ID 268 gen 11733 top level 5 path @opt

So, is this correct?  It would have been good if there was a direct way 
to add the level that you wanted the subvolume created & mounted with 
the btrfs command.  So if I take a snapshot of @, /opt won't be 
included?  That'd my goal.  I've been using btrfs at a very basic level, 
added on top of an md raid1.  It worked well for a number of years, but 
then I needed to replace the disks, I thought I'd go all in on btrfs.

Thanks for your help!

     -John


On 5/2/22 9:16 AM, Chris Murphy wrote:
> On Sun, May 1, 2022 at 8:02 PM John Center <jlcenter15@gmail.com> wrote:
>> Hi Hugo,
>>
>> Thanks for responding.  I guess what I don't understand, @home is a
>> subvolume, but it appears as /home when it is mounted via fstab.  It has
>> a top level ID of 5.  If I create a subvolume for opt, it has a top
>> level of 256.  I've tried different variations of opt, /opt, & @opt, but
>> they all appear as that variation under /:
>>
>> john@Mariposa:~$ sudo btrfs subvolume create /@opt
>> Create subvolume '//@opt'
> This is the mistake. Since @ is mounted at /, using /@opt actually
> means /@/@opt, thus it's been nested.
>
>> john@Mariposa:~$ sudo btrfs subvolume list /
>> ID 256 gen 5968 top level 5 path @
>> ID 257 gen 5968 top level 5 path @home
>> ID 259 gen 5966 top level 256 path @opt
> @opt was created inside @, that's why it looks like this. Thus, @opt
> is nested within @. Thus, @ and @home follow a flat layout. And @opt
> follows a nested layout. To continue with the flat layout for @opt
> you'd need to create the @opt subvolume in the top-level of the file
> system alongside @ and @home rather than within one of them. To create
> it in the top-level you need to mount the top-level somewhere, e.g.
>
> btrfs subvolume get-default /
>
> Assuming this refers to ID 5, then you just
>
> mount /dev/sdXY /mnt
> btrfs subvolume create /mnt/@opt
>
> And the fstab entry should be subvol=@opt
>
> If get-default reports a value other than 5, then you need to
> explicitly mount the top level:
>
> mount -o subvol=/ /dev/sdXY /mnt       OR
> mount -o subvolid=5 /dev/sdXY /mnt    OR
> mount -o subvolid=0 /dev/sdXY /mnt
>
> The top-level subvolume was assigned ID 5 during initial creation of
> the file system. Soon after, ID 0 was set up as an alias for 5 because
> maybe it'd be easier to remember.
>
> Note: The top-level nomenclature used by btrfs subvolume list is
> considered confusing, and I think it's going away in btrfs-progs
> soonish? The "top-level" of the file system is considered equivalent
> to subvolume ID 5, which has no name, cannot be renamed or removed,
> but can be snapshot, and is the subvolume created at mkfs time. Above,
> it sounds like there's multiple "top-level" subvolumes, e.g. 5 and
> 256. But in practice it's not how anyone is using the term "top
> level", which these days is intended to refer to just ID 5. The
> subvolume with no (explicit) name.
>
>
>
>> john@Mariposa:~$ sudo btrfs subvolume delete /@opt
>> Delete subvolume (no-commit): '//@opt'
>>
>> john@Mariposa:~$ sudo btrfs subvolume create /opt
>> Create subvolume '//opt'
> Yep, / is still the @ subvolume here, because @ is bind mounted to /
>
>
>> So, what am I missing between what I'm seeing vs what I think I should
>> be seeing?
> It'd be neat if we had a way to create subvolumes in the top level
> directly without having to mount the top level. The FD variant of the
> C API found in libbtrfsutil suggests it's possible. And also we have a
> way to delete subvolumes by subvolid, even when they aren't locatable
> via the mounted file system hierarchy, using the --subvolid flag.
>
>
>
>