public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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