linux-unionfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	overlayfs <linux-unionfs@vger.kernel.org>,
	Fabian <godi.beat@gmx.net>
Subject: Re: overlayfs: issue with a replaced lower squashfs with export-table
Date: Wed, 8 Jul 2020 13:36:01 -0400	[thread overview]
Message-ID: <20200708173601.GD103536@redhat.com> (raw)
In-Reply-To: <CAOQ4uxhNqbtL_G+ZxB+UwK+c+P2fbvis1ZP7XXtO=R=N6Or_ew@mail.gmail.com>

On Wed, Jul 08, 2020 at 08:26:19PM +0300, Amir Goldstein wrote:
> On Wed, Jul 8, 2020 at 5:27 PM Vivek Goyal <vgoyal@redhat.com> wrote:
> >
> > On Wed, Jul 08, 2020 at 10:23:53AM -0400, Vivek Goyal wrote:
> > > On Wed, Jul 08, 2020 at 11:50:29AM +0300, Amir Goldstein wrote:
> > > > On Wed, Jul 8, 2020 at 11:37 AM Miklos Szeredi <miklos@szeredi.hu> wrote:
> > > > >
> > > > > On Wed, Jul 8, 2020 at 10:31 AM Amir Goldstein <amir73il@gmail.com> wrote:
> > > > >
> > > > > >
> > > > > > 1) is not problematic IMO and the simple patch I posted may be applied
> > > > > > for fixing the reported issue, but it only solved the special case of null uuid.
> > > > > > The problem still exists with re-creating lower on xfs/ext4, e.g. by
> > > > > > rm -rf and unpacking image tar.
> > > > >
> > > > > How so?  st_ino may be reused but the fh is guaranteed to be unique.
> > > > >
> > > >
> > > > Doh! You are right. I was talking nonsense.
> > > > The only problem would be with re-creating an xfs/ext4 lower image
> > > > with the same uuid maybe because a basic image is cloned.
> > > >
> > > > In any case, it's a corner of a corner of a corner.
> > > > I will post the patch to fix null uuid.
> > >
> > > It will also be good if we can bring some clarity to the documentation
> > > for future references in section "Sharing and copying layers".
> 
> I am very bad at documenting.
> Feel free to post a patch to add clarity.

Ok, I will send a patch and improve it based on feedback.

> 
> > >
> > > So if IIUC,
> > >
> > > - sharing layers should work with all features of overlayfs.
> > >
> > > - copying layers works only if index and nfs_export is not enabled. Even
> > >   if index is not enabled, copying layers will change inode number
> > >   reporting behavior (as origin verification will fail). We probably
> > >   say something about this.
> > >
> > > - Modifying/recreating lower layer only works when
> > >   metacopy/index/nfs_export are not enabled at any point of time. This
> > >   also will change inode number reporting behavior.
> >
> > Well, this is not entirely true. redirect might be broken if lower layers have
> > been modified/recreated and that will have issues with directories.
> >
> > /me is again wondering what's the use case of modifying lower layer
> > with an existing upper. Is it fair to say, no don't recreate/modify
> > lower layers and use with existing upper.
> >
> 
> It's fine by me to document that this is not supported.
> Only thing is that we usually do not want to break existing setups that
> used to work if we dont have to.

I will limit this case to "!redirect, !metacopy, !index, !export"
and that will make sure existing setups work and any of the new features
we added will not support this.

Thanks
Vivek


      reply	other threads:[~2020-07-08 17:36 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-06 13:27 overlayfs: issue with a replaced lower squashfs with export-table Fabian
2020-07-06 14:29 ` Amir Goldstein
2020-07-06 15:14   ` Fabian
2020-07-06 15:33     ` Amir Goldstein
2020-07-06 16:10       ` Fabian
2020-07-06 17:14         ` Amir Goldstein
2020-07-16 13:29           ` Fabian Godehardt
2020-07-07  5:51     ` Amir Goldstein
2020-07-07 15:51       ` Vivek Goyal
2020-07-07 17:41         ` Amir Goldstein
2020-07-07 21:53           ` Vivek Goyal
2020-07-08  6:55             ` Amir Goldstein
2020-07-08  8:00               ` Miklos Szeredi
2020-07-08  8:31                 ` Amir Goldstein
2020-07-08  8:37                   ` Miklos Szeredi
2020-07-08  8:50                     ` Amir Goldstein
2020-07-08 14:23                       ` Vivek Goyal
2020-07-08 14:26                         ` Vivek Goyal
2020-07-08 17:26                           ` Amir Goldstein
2020-07-08 17:36                             ` Vivek Goyal [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200708173601.GD103536@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=amir73il@gmail.com \
    --cc=godi.beat@gmx.net \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).