Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756842AbcKETpk (ORCPT ); Sat, 5 Nov 2016 15:45:40 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:36085 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756660AbcKETph (ORCPT ); Sat, 5 Nov 2016 15:45:37 -0400 MIME-Version: 1.0 X-Originating-IP: [217.173.44.24] In-Reply-To: References: <20161104093050.GB1839@veci.piliscsaba.szeredi.hu> From: Miklos Szeredi Date: Sat, 5 Nov 2016 20:45:35 +0100 Message-ID: Subject: Re: [GIT PULL] overlayfs fixes for 4.9-rc3 To: Linus Torvalds Cc: Amir Goldstein , Linux Kernel Mailing List , linux-fsdevel , "linux-unionfs@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1644 Lines: 40 On Sat, Nov 5, 2016 at 6:41 PM, Linus Torvalds wrote: > On Fri, Nov 4, 2016 at 11:44 PM, Amir Goldstein 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