lkml.org 
[lkml]   [2016]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [GIT PULL] overlayfs fixes for 4.9-rc3
On Sat, Nov 5, 2016 at 6:41 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, Nov 4, 2016 at 11:44 PM, Amir Goldstein <amir73il@gmail.com> wrote:
>>
>> Can you please clarify your objection?
>
> There are several:
>
> - timing. No way in hell will I take a new feature like this during an rc

I can do it next merge window; the reason I wanted this patch in as
early as possible because, as I said, it's already too late. But it's
no big deal.

> - lack of explanation. Why is this bad feature needed in the first
> place? Why would overlayfs versioning _ever_ be a good idea?

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.

>
> - is the implementation even sane? Right now I don't think overlayfs
> even requires xattr support in the upper filesystem, so the whole
> concept seems frankly totally misdesigned.

overlayfs relies on xattr to create opaque directories (i.e. you
remove a directory (residing on the lower layer) and create one with
the same name). So it is needed for normal r/w operation. And
definitely for the above feature which also uses xattr.

Thanks,
Miklos

\
 
 \ /
  Last update: 2016-11-05 20:46    [W:0.052 / U:1.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site