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

David Sterba
2024-08-14T21:57:11Z

On Tue, Aug 13, 2024 at 07:38:22AM +0930, Qu Wenruo wrote:
> 在 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.

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.

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.

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.