Re: [PATCH v5] btrfs-progs: add --subvol option to mkfs.btrfs

Goffredo Baroncelli
2024-08-12T11:45:07Z

On 11/08/2024 00.40, Qu Wenruo wrote:
>
>
> 在 2024/8/10 19:23, Goffredo Baroncelli 写道:
>> On 09/08/2024 21.31, David Sterba wrote:
>>> On Thu, Aug 08, 2024 at 06:17:16PM +0100, Mark Harmstone wrote:
>>>> This patch adds a --subvol option, which tells mkfs.btrfs to create the
>>>> specified directories as subvolumes.
>>>>
>>>> Given a populated directory img, the command
>>>>
>>>> $ mkfs.btrfs --rootdir img --subvol img/usr --subvol img/home
>>>> --subvol img/home/username /dev/loop0
>>>>
>>>> will create subvolumes usr and home within the FS root, and subvolume
>>>> username within the home subvolume. It will fail if any of the
>>>> directories do not yet exist.
>>>
>>> Can this be fixed so the intermediate directories are created if they
>>> don't exist? So for example
>>>
>>> mkfs.btrfs --rootdir dir --subvolume /var/lib/images
>>>
>>> where dir contains only /var. I don't think it's that common but we
>>> should not make users type something can be done programmaticaly.
>>
>> Can we go a bit further ? I mean get rid of --rootdir completely, so
>> a filesystem with "a default" subvolume can be created without
>> passing --rootdir.
>
> Personally speaking, I would prefer the current scheme way more than the
> out of tree subvolumes.
>
> It's super easy to have something like this:
>
> rootdir
> |- dir1
> |- dir2
>
> Then you specify "--rootdir rootdir and --subvolume /somewhereelse/dir1"
>
> This is going to lead filename conflicts and mostly an EEXIST to end the
> operation.

I am not sure to fully understand to what you means as "filename conflicts";
anyhow, now you have the ENOEXIST problem :-)

>
>
> From my understand, the "--rootdir" along with "--subvol" is mostly
> used to populate a fs image for distro building.
>
> If you really want just a single subvolume, why won't "--rootdir rootdir
> --subvol dir1" work for you?
>
> If your only goal is to reduce parameters, then your next question is
> already answering why the idea is a bad one.

The use case that I have in my mind is to create a filesystem with a default
non root sub-volume, and nothing more. This would prevent the typical problem
that you face when you populate the root-subvolume, then snapshot it and then
revert to an old snapshot, swapping the subvolumes.
It is not easy to swap the root subvolume, because it is a special in the sense
that it cannot be deleted and it is the root of all subvolumes.

Being so I think that it is better to avoid to have the root subvolume as
default sub-volume.

For my goal (having a filesystem with a non root default sub-volume) creating a
template filesystem is waste of effort.

Now these two use cases (my one, and the one related to this patch) have a lot
in common. So I trying to find a way so the two can be joined.

>
>>
>> However, this would lead to the queston: which user and permission has
>> to be set to those subvolumes ?
>> So I think that we need a further parameter like "--subvol-perm" and
>> "--subvol-owner"...
>
> Nope, the current code is already handling that way better.
> The user/owner and modes are from the rootdir.
>
> Meanwhile your idea is just asking for extra problems.
>
> Thanks,
> Qu
>
>>
>> BR
>>

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