From: Linus Torvalds <torvalds@linux-foundation.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Amir Goldstein <amir73il@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
"linux-unionfs@vger.kernel.org" <linux-unionfs@vger.kernel.org>
Subject: Re: [GIT PULL] overlayfs fixes for 4.9-rc3
Date: Sat, 5 Nov 2016 14:30:21 -0700 [thread overview]
Message-ID: <CA+55aFzn7RvHfbYkRmJZ2LWbAVHGBSPoAMQNkKh7DsOYX82_9w@mail.gmail.com> (raw)
In-Reply-To: <CAJfpegs6e_K7y-CPj4dm1qtoF6h1z0dFrXHxJSc8TsV=ckuEbA@mail.gmail.com>
On Sat, Nov 5, 2016 at 12:45 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> The feature that would be introduced is this: allow directory renames
> to work without having to recursively copy-up the subtree. Whatever
> mechanism is devised to do this will be backward incompatible. Maybe
> it's a misguided idea, but it's been through several rounds of reviews
> on the relevant mailing lists and there weren't any objections (yet).
>
> And the thing is, backward incompatibility is less of an issue for
> overlayfs than for normal filesystems, because it's usually not
> something people store their root filesystems on, and if so they can
> simply not turn off this feature.
(a) that should be explained
(b) that has nothing to do with being marked for stable
(c) that new doesn't actually explain in any way why you'd want
"feature flags" thing, for exactly the same "backwards incompatibility
is less of an issue" reason that you state.
Why not "just do it", in other words. For exactly the reasons you say.
Make it a mount option that people can choose to use or not.
> overlayfs relies on xattr to create opaque directories
Yes and no. It relies on it for THAT ONE FEATURE, which you don't have
to use. As far as I can tell, overlayfs does *not* rely on xattrs in
general.
Linus
next prev parent reply other threads:[~2016-11-05 21:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-04 9:30 [GIT PULL] overlayfs fixes for 4.9-rc3 Miklos Szeredi
2016-11-05 3:06 ` Linus Torvalds
2016-11-05 6:44 ` Amir Goldstein
2016-11-05 17:41 ` Linus Torvalds
2016-11-05 19:45 ` Miklos Szeredi
2016-11-05 21:30 ` Linus Torvalds [this message]
2016-11-05 21:41 ` Peter Rosin
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=CA+55aFzn7RvHfbYkRmJZ2LWbAVHGBSPoAMQNkKh7DsOYX82_9w@mail.gmail.com \
--to=torvalds@linux-foundation.org \
--cc=amir73il@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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;
as well as URLs for NNTP newsgroup(s).