Re: [GIT PULL] overlayfs fixes for 4.9-rc3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Nov 5, 2016 at 6:41 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Fri, Nov 4, 2016 at 11:44 PM, Amir Goldstein <amir73il@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux