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

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

在 2024/8/12 21:12, Goffredo Baroncelli 写道:
> On 11/08/2024 00.40, Qu Wenruo wrote:
[...]
>>
>> 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 :-)

I mean, if you support specifying a out of rootdir subvolume, along with
rootdir, then it's going to cause conflicts (the file from rootdir with
the same filename conflicts with the out-of-rootdir subvolume)
>
>>
>>
>>  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.

You ignored all the things like owner/group/privilege bits and maybe
even xattrs (for SELINUX) that will be needed.


> 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.

A seemingly simple solution is not always that simple.

And I can always argue that, for your "simple" subvolume case, why not
just mount it and create one?
Especially that one needs to set the default subvolume of the fs anyway.

>
> 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.

Unfortunately, as long as you're creating a subvolume, you need all the
details you ignored (which makes the use case looking simple).

In that case, it's just a subset of the feature of Mark's patch.

Meanwhile Mark's solution provides all the information needed, thus I
see no reason to introduce extra interfaces especially when Mark's
solution is already a superset.

Thanks,
Qu
>
>>
>>>
>>> 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
>>>
>
>