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>
Subject: Re: [PATCH v2] overlay: allow config override of metacopy/redirect defaults
Date: Mon, 10 Jun 2019 14:45:53 -0400 [thread overview]
Message-ID: <20190610184553.GE25290@redhat.com> (raw)
In-Reply-To: <20190610184043.GD25290@redhat.com>
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.
Vivek
next prev parent reply other threads:[~2019-06-10 18:45 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 [this message]
2019-06-11 12:37 ` Miklos Szeredi
2019-06-11 13:09 ` Vivek Goyal
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=20190610184553.GE25290@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 \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.