From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: kreijack@inwind.it, Mark Harmstone <maharmstone@fb.com>,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v5] btrfs-progs: add --subvol option to mkfs.btrfs
Date: Wed, 14 Aug 2024 23:57:03 +0200 [thread overview]
Message-ID: <20240814215703.GB25962@suse.cz> (raw)
In-Reply-To: <77cda2a4-08ae-47b9-8efd-e3ca0e8fe9bc@gmx.com>
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.
next prev parent reply other threads:[~2024-08-14 21:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-08 17:17 [PATCH v5] btrfs-progs: add --subvol option to mkfs.btrfs Mark Harmstone
2024-08-09 19:31 ` David Sterba
2024-08-10 9:53 ` Goffredo Baroncelli
2024-08-10 22:40 ` Qu Wenruo
2024-08-12 11:42 ` Goffredo Baroncelli
2024-08-12 14:39 ` Mark Harmstone
2024-08-12 22:08 ` Qu Wenruo
2024-08-14 21:57 ` David Sterba [this message]
2024-08-14 22:11 ` Qu Wenruo
2024-08-14 22:20 ` David Sterba
2024-08-13 0:52 ` Anand Jain
2024-08-13 10:38 ` Mark Harmstone
2024-08-14 21:47 ` David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240814215703.GB25962@suse.cz \
--to=dsterba@suse.cz \
--cc=kreijack@inwind.it \
--cc=linux-btrfs@vger.kernel.org \
--cc=maharmstone@fb.com \
--cc=quwenruo.btrfs@gmx.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox