From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vivek Goyal Subject: Re: [PATCH v9 00/15] overlayfs: Delayed copy up of data Date: Mon, 8 Jan 2018 10:44:37 -0500 Message-ID: <20180108154437.GC9910@redhat.com> References: <20171129155448.32721-1-vgoyal@redhat.com> <20180108141335.GB9910@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mx1.redhat.com ([209.132.183.28]:45574 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932282AbeAHPoi (ORCPT ); Mon, 8 Jan 2018 10:44:38 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-unionfs-owner@vger.kernel.org List-Id: linux-unionfs@vger.kernel.org To: Amir Goldstein Cc: overlayfs , Miklos Szeredi On Mon, Jan 08, 2018 at 04:42:59PM +0200, Amir Goldstein wrote: > On Mon, Jan 8, 2018 at 4:13 PM, Vivek Goyal wrote: > > On Sat, Jan 06, 2018 at 09:38:07AM +0200, Amir Goldstein wrote: > >> On Wed, Nov 29, 2017 at 5:54 PM, Vivek Goyal wrote: > >> > Hi, > >> > > >> > Please find attached V9 of the patches. Minor changes to take care of > >> > Amir's comments. I have also dropped RFC tag. If there are no concerns, > >> > then I would like these patches to be included. > >> > > >> > >> Sorry Vivek, just realized some issues: > >> > >> 1. Considering Miklos' commit > >> 438c84c2f0c7 ovl: don't follow redirects if redirect_dir=off > >> It is probably not a good idea to allow lookup of metacopy unless > >> metacopy=on. Is that already the behavior in V9? > > > > Hi Amir, > > > > Hmm.., no, that's not the behavior in V9. Remember, we wanted to follow > > metacopy origin even if metacopy=off. That way a user can mount a > > overlayfs with metacopy=off (which was previously mounted as metacopy=on) > > and not be broken. > > > > User can also mount with redirect_dir=nofollow after previously mounting with > redirect_dir=on. It's the exact same thing. > > > If we follow metacopy only if metacopy=on, then we really need some > > mechanism which can atleast warn user that this overlay mount was > > mounted with metacopy=on in the past and expect some unexpected results > > if mounted with metacopy=off. > > > > Has there been any agreement on what mechanism to use to remember what > > features have been turned on existing overlay mount. > > > > There is no agreement, but there is code in upstream that "allows" the user > to make the same with redirect_dir. The consequences of this configuration is > -EPERM on lookup. > You actually have to allow this configuration for security reasons, the only > question is whether metacopy will have 3 modes (off/follow/on) or just on/off > where off implies nofollow. Ok, I will also return -EPERM of metacopy xattr is found but metacopy=on is not set. We can introduce metacopy=follow later if need be. Right now I can't think how it will be useful. Once we have a use case, adding it should be easy as there are not backward compatibility issues to deal with. Vivek