Linux Overlay Filesystem development
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Amir Goldstein <amir73il@gmail.com>,
	Matt Coffin <mcoffin13@gmail.com>,
	overlayfs <linux-unionfs@vger.kernel.org>,
	Daniel J Walsh <dwalsh@redhat.com>,
	Nalin Dahyabhai <nalin@redhat.com>
Subject: Re: [PATCH v2] overlay: allow config override of metacopy/redirect defaults
Date: Tue, 11 Jun 2019 09:09:32 -0400	[thread overview]
Message-ID: <20190611130932.GA28835@redhat.com> (raw)
In-Reply-To: <CAJfpegvrOy3yBpu1AVBFyjdXBNM44k4gSqQ0F2npBG8wH8cUeg@mail.gmail.com>

On Tue, Jun 11, 2019 at 02:37:34PM +0200, Miklos Szeredi wrote:
> On Mon, Jun 10, 2019 at 8:45 PM Vivek Goyal <vgoyal@redhat.com> wrote:
> >
> > On Mon, Jun 10, 2019 at 02:40:43PM -0400, Vivek Goyal wrote:
> > > On Sun, Jun 09, 2019 at 09:14:38PM +0200, Miklos Szeredi wrote:
> > > > On Sat, Jun 8, 2019 at 8:47 PM Amir Goldstein <amir73il@gmail.com> wrote:
> > > >
> > > > > And then every time that a feature needs to be turned off for some reason
> > > > > that also needs to be taken into account.
> > > > > IOW, I advise against diving into this mess. You have been warned ;-)
> > > >
> > > > Also a much more productive direction would be to optimize building
> > > > the docker image based on the specific format used by overlayfs for
> > > > readirect_dir/metacopy.
> > > >
> > > > To me it seems like a no-brainer, but I don't know much about docker, so...
> > >
> > > [ cc Daniel Walsh]
> > >
> > > Hi Miklos,
> > >
> > > Can you elaborate a bit more on what docker/container-storoage and do
> > > here to expedite image generation with redirect_dir/metacopy enabled.
> > >
> > > They can't pack these xattrs in image because image will not be portable.
> > > It will be overlayfs specific and can't be made to work on target without
> > > overlayfs.
> >
> > Are you referring to apps being able to traverse lower layers and do
> > the redirect_dir and metacopy resoltion as kernel does. To me that process
> > is not trivial. Having a library might help with adoption though.
> 
> AFAICS what happens when generating a layer is to start with a clean
> upper layer, do some operations, then save the contents of the upper
> layer.  If redirect or metacopy is enabled, then the contents of the
> upper layer won't be portable.  So need to do something like this:
> 
> traverse(overlay_dir, upper_dir, target_dir)
> {
>     iterate name for entries in $upper_dir {
>         if ($name is non-directory) {
>             copy($overlay_dir/$name, $target_dir/$name)
>         } else if ($name is redirect) {
>             copy-recursive($overlay_dir/$name, $target_dir/$name)
>         } else {
>             copy($overlay_dir/$name, $target_dir/$name)
>             traverse($overlay_dir/$name, $upper_dir/$name, $target_dir/$name)
>         }
>     }
> }
> 
> Basically: traverse the *upper layer* but copy files and directories
> from the *overlay*.  Does that make sense?

[ cc nalin ]

Aha... This makes sense to me. This does away with need of separate
library or user space tool and hopefully its faster than naivediff
interface. 

Dan, Nalin, what do you think about above idea.

Thanks
Vivek

  reply	other threads:[~2019-06-11 13:09 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-07  1:04 [PATCH] overlay: allow config override of metacopy/redirect defaults Matt Coffin
2019-06-07 20:51 ` [PATCH v2] " Matt Coffin
2019-06-08  9:04   ` Amir Goldstein
2019-06-08 17:28     ` Matt Coffin
2019-06-08 18:47       ` Amir Goldstein
2019-06-09 19:14         ` Miklos Szeredi
2019-06-10 18:40           ` Vivek Goyal
2019-06-10 18:45             ` Vivek Goyal
2019-06-11 12:37               ` Miklos Szeredi
2019-06-11 13:09                 ` Vivek Goyal [this message]
2019-06-11 21:44                   ` Daniel Walsh
2019-06-11 21:49                     ` Vivek Goyal
2019-06-11 21:57                       ` Matt Coffin
2019-06-11 23:09                         ` Daniel Walsh
2019-06-12 12:32                         ` Vivek Goyal
2019-06-10 18:30     ` Vivek Goyal
2019-06-10 18:51       ` Amir Goldstein

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=20190611130932.GA28835@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=amir73il@gmail.com \
    --cc=dwalsh@redhat.com \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=mcoffin13@gmail.com \
    --cc=miklos@szeredi.hu \
    --cc=nalin@redhat.com \
    /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