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

Qu Wenruo
2024-08-10T22:40:33Z

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

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.

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