From: Vivek Goyal <vgoyal@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Amir Goldstein <amir73il@gmail.com>,
yangerkun <yangerkun@huawei.com>,
"zhangyi (F)" <yi.zhang@huawei.com>,
Miao Xie <miaoxie@huawei.com>,
overlayfs <linux-unionfs@vger.kernel.org>
Subject: Re: [QUESTION] problem about origin xattr
Date: Wed, 31 Jan 2018 11:55:22 -0500 [thread overview]
Message-ID: <20180131165522.GD8087@redhat.com> (raw)
In-Reply-To: <CAJfpegtpsV+T6kMAVy9+Mr_1kuk4xWUeYaa6MPTzKNjJ28Nq=A@mail.gmail.com>
On Wed, Jan 31, 2018 at 05:10:28PM +0100, Miklos Szeredi wrote:
> On Wed, Jan 31, 2018 at 4:58 PM, Amir Goldstein <amir73il@gmail.com> wrote:
> > On Wed, Jan 31, 2018 at 5:46 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> >> On Wed, Jan 31, 2018 at 05:38:45PM +0200, Amir Goldstein wrote:
> >>> On Wed, Jan 31, 2018 at 5:20 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> >>> > On Wed, Jan 31, 2018 at 03:57:12PM +0200, Amir Goldstein wrote:
> >>> >
> >>> > ORIGIN behavior is little unintuitive though. Despite the fact that file
> >>> > is not searchable through lower, it is visible through decoding of file
> >>> > handle and it is atleast non-intuitive.
> >>> >
> >>>
> >>> Maybe not intuitive at first glance, but try again:
> >>>
> >>> The only thing we *need* from underlying fs is to provide us with a unique
> >>> and persistent inode number we can use for the overlay object.
> >>>
> >>> Even if the inode number we get from underlying fs is not in any of the
> >>> layers, it is still a viable inode number we can use in overlay coupled
> >>> with overlay unique st_dev, to create a system wide unique st_dev;st_ino
> >>> tuple.
> >>
> >> As long as we use only inode number, it probably is still fine.
> >>
> >> But I look at ORIGIN as a generic infrastructure which other features can
> >> make use of it. For example, metacopy is using it to copy up file later.
> >> And there it will be non-intuitive that a file is not in any of the
> >> lower, still ORIGIN was decoded and file was copied up. It can come
> >> as a surprise to user. Atleast I was surprised when I ran into this
> >> while testing the feature.
>
> How about using REDIRECT for metacopy origin? Keeping ORIGIN only
> for inode, also meaning ORIGIN is only ever used on upper layer, never
> on middle layers.
Hi Miklos,
Trying to understand it better. So proposal seems to be that when a file
is copied up metacopy only, we store both REDIRECT and ORIGIN in upper
inode. When traversing metacopy inode chain, use ORIGIN info on upper
inode and REDIRECT info on lower/midlayer metacopy inode.
I am assuming that this is to handle the use case of tar of upper layer
and untaring it as lower layer.
One of the concerns Amir had raised with usage of REDIRECT was that it
will be significantly slower as comapred to decoding ORIGIN. So by using
ORIGIN on upper, we are trying to mitigate it up to some extent? We will
still pay the cost of decoding REDIECT in midlayer.
Am I understanding it right.
Vivek
next prev parent reply other threads:[~2018-01-31 16:55 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-31 10:36 [QUESTION] problem about origin xattr yangerkun
[not found] ` <CAOQ4uxhGmD2g4Z9EY504OfssyiVvUskKGec0vqraHOHia88PPQ@mail.gmail.com>
[not found] ` <20180131152041.GA8087@redhat.com>
2018-01-31 15:38 ` Amir Goldstein
2018-01-31 15:46 ` Vivek Goyal
2018-01-31 15:58 ` Amir Goldstein
2018-01-31 16:10 ` Miklos Szeredi
2018-01-31 16:55 ` Vivek Goyal [this message]
2018-01-31 18:08 ` Miklos Szeredi
2018-01-31 19:05 ` Vivek Goyal
2018-01-31 19:59 ` Amir Goldstein
2018-01-31 20:34 ` Vivek Goyal
2018-01-31 20:48 ` Miklos Szeredi
2018-01-31 20:58 ` Vivek Goyal
2018-01-31 21:06 ` Miklos Szeredi
2018-01-31 21:12 ` Vivek Goyal
2018-01-31 23:26 ` Amir Goldstein
2018-02-01 15:25 ` Vivek Goyal
2018-02-01 16:22 ` Amir Goldstein
2018-02-01 3:57 ` yangerkun
2018-02-01 5:37 ` 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=20180131165522.GD8087@redhat.com \
--to=vgoyal@redhat.com \
--cc=amir73il@gmail.com \
--cc=linux-unionfs@vger.kernel.org \
--cc=miaoxie@huawei.com \
--cc=miklos@szeredi.hu \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.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 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.