Re: [PATCH v9 00/15] overlayfs: Delayed copy up of data

[Vivek Goyal <vgoyal@redhat.com>]

On Mon, Jan 08, 2018 at 04:42:59PM +0200, Amir Goldstein wrote:
> On Mon, Jan 8, 2018 at 4:13 PM, Vivek Goyal <vgoyal@redhat.com> 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 <vgoyal@redhat.com> 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