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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
