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

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

在 2024/8/15 07:27, David Sterba 写道:
[...]
>>
>> You ignored all the things like owner/group/privilege bits and maybe
>> even xattrs (for SELINUX) that will be needed.
>
> There are probably two main use cases:
>
> - create something simple, with files copied from a directory and now
>    newly also to make some directories subvolumes
>
> - create a filesystem where any detail can be specified, like uid/gid,
>    access rights, ACL, XATTR, ...
>
> So far the focus is on option 1 and it seems we have the most common use
> covered. For option 2 the command line options are probably the wron
> interface.

Nope, the current implementation (inherited from the --rootdir option)
handles both.

We have everything, except the hardlinks, copied from the rootdir,
including uid/gid/access mode, XATTR.

>
> I suggest to use an approach using a list of definitions, e.g. in a
> file, where each line says what should be done on the filesystem. This
> is not a new idea, XFS has a protofile, which is ancient and we don't
> have to copy the exact format, but it's the same idea.

I think it's asking for problems that is already resolved.

The current rootdir is already providing every functionality, except
subvolume related ones (subvolume, snapshot, default subvolume etc).

And Mark's excellent work handles the missing subvolume part, and he is
also working on the default subvolume part too.

So far I really see no reason to introduce a completely new and complex
(and conflicting with --rootdir) interface, while everything can be done
by --rootdir + --subvol already.

The only exception is snapshot, but for mkosi usage, I didn't see much
need for a snapshot.

Thanks,
Qu

>
> The structure is like this:
>    COMMAND OPTIONS...
>
> and we can define anything, like "ROOTDIR dir" that will mimick the
> --rootdir option, but also "CHMOD RWX PATH", to do mkfs-emulated
> "chmod RWX PATH". And custom commands like default subvolume.
>
> This is obviously more work than option 1 so does not need to be
> implemented right now. For the command-line options the most common use
> case should work. If we allow to take the proto file from stdin it can
> be created on the fly too.