From: Vivek Goyal <vgoyal@redhat.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: overlayfs <linux-unionfs@vger.kernel.org>,
Miklos Szeredi <miklos@szeredi.hu>
Subject: Re: [PATCH v10 07/18] ovl: Add mechanism to create a chain of origin dentries
Date: Tue, 23 Jan 2018 09:13:57 -0500 [thread overview]
Message-ID: <20180123141357.GD2755@redhat.com> (raw)
In-Reply-To: <CAOQ4uxhU15nXU32+q6_krm=c_xY=OBaAmJF4xk7CMbeDur4oKw@mail.gmail.com>
On Tue, Jan 23, 2018 at 03:47:29PM +0200, Amir Goldstein wrote:
> On Tue, Jan 23, 2018 at 3:45 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > On Mon, Jan 22, 2018 at 09:46:33PM +0200, Amir Goldstein wrote:
> >> On Mon, Jan 22, 2018 at 9:34 PM, Amir Goldstein <amir73il@gmail.com> wrote:
> >> > On Mon, Jan 22, 2018 at 8:39 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> >> >> There is a need to support metacopy dentry in midlayer. That means there
> >> >> could be a chain of metacopy dentries.
> >> >>
> >> >> For example, upper could be metacopy, midlayer lower could be metacopy and
> >> >> lowest layer could be actual data inode. This means when we copy up actual
> >> >> data, we should be able to reach to lowest data inode and copy up data from
> >> >> there. And that means we should keep track of all the dentries in origin
> >> >> chain which lead to data inode.
> >> >>
> >> >> Current ovl_check_origin() logic only looks for one origin dentry. This patch
> >> >> enhances ovl_check_origin() to continue to follow origin chain and return
> >> >> all the origin entries found. This is done only if caller of the function
> >> >> set "follow_chain" argument.
> >> >>
> >> >
> >> > We don't really need to keep the entire chain do we?
> >> > We can follow chain but keep only the one inode that is not a metacopy inode.
> >> > All the rest are useless, no?
> >> > Then we don't create a new type of object - non-dir with numlower > 1.
> >> >
> >>
> >> Seems like if you don't keep the entire chain, then no need for
> >> patches 14 and 15.
> >
> > I will need to have atleast 2 lower dentries. One will be top most
> > metadata copy and other lower most data dentry. IOW, both the ends of
> > the chain need to be there.
> >
> >> Also with upper metacopy, you can fix upper origin xattr after
> >> following to the data
> >> origin and forget about middle layer metacopies forever.
> >
> > If upper metacopy is alreday there, then I agree that lower top most
> > becomes inner node of chain and we can get rid of it.
> >
> >>
> >> Am I missing something?
> >
> > I think you are missing the case when there is no upper and lower has
> > a metacopy chain. In that case we need to retain two dentries. One for
> > data copy up and one for metadata copy up.
> >
>
> OK. so you can get rid of all the middle metacopies while following
> the origin chain. no reason to keep those.
Sure, will do that. As of now there are no users of intermediate nodes.
Once somebody needs these, code can be modified.
Vivek
next prev parent reply other threads:[~2018-01-23 14:13 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-22 18:39 [PATCH v10 00/18] overlayfs: Delayed copy up of data Vivek Goyal
2018-01-22 18:39 ` [PATCH v10 01/18] ovl: Do not look for OVL_XATTR_NLINK if index is not there Vivek Goyal
2018-01-22 18:39 ` [PATCH v10 02/18] ovl: disable redirect_dir and index when no xattr support Vivek Goyal
2018-01-22 18:39 ` [PATCH v10 03/18] ovl: Create origin xattr on copy up for all files Vivek Goyal
2018-01-22 18:39 ` [PATCH v10 04/18] ovl: Provide a mount option metacopy=on/off for metadata copyup Vivek Goyal
2018-01-22 18:39 ` [PATCH v10 05/18] ovl: During copy up, first copy up metadata and then data Vivek Goyal
2018-01-22 18:39 ` [PATCH v10 06/18] ovl: Move the copy up helpers to copy_up.c Vivek Goyal
2018-01-22 18:39 ` [PATCH v10 07/18] ovl: Add mechanism to create a chain of origin dentries Vivek Goyal
2018-01-22 19:34 ` Amir Goldstein
2018-01-22 19:46 ` Amir Goldstein
2018-01-23 13:45 ` Vivek Goyal
2018-01-23 13:47 ` Amir Goldstein
2018-01-23 14:13 ` Vivek Goyal [this message]
2018-01-30 19:33 ` Vivek Goyal
2018-01-30 20:03 ` Amir Goldstein
2018-01-30 20:05 ` Amir Goldstein
2018-01-30 20:15 ` Vivek Goyal
2018-01-30 21:01 ` Amir Goldstein
2018-01-30 20:06 ` Vivek Goyal
2018-01-23 13:40 ` Vivek Goyal
2018-01-22 18:39 ` [PATCH v10 08/18] ovl: Copy up only metadata during copy up where it makes sense Vivek Goyal
2018-01-22 18:39 ` [PATCH v10 09/18] ovl: Add helper ovl_already_copied_up() Vivek Goyal
2018-01-22 18:39 ` [PATCH v10 10/18] ovl: A new xattr OVL_XATTR_METACOPY for file on upper Vivek Goyal
2018-01-22 18:39 ` [PATCH v10 11/18] ovl: Set OVL_UPPERDATA flag during ovl_lookup() Vivek Goyal
2018-01-22 18:39 ` [PATCH v10 12/18] ovl: Setup origin chain for lower regular files Vivek Goyal
2018-01-22 18:39 ` [PATCH v10 13/18] ovl: Check metacopy attributes on a chain of origin Vivek Goyal
2018-01-22 18:40 ` [PATCH v10 14/18] ovl: Do not mark a non dir as _OVL_PATH_MERGE in ovl_path_type() Vivek Goyal
2018-01-22 18:40 ` [PATCH v10 15/18] ovl: Copy up meta inode data from lowest data inode Vivek Goyal
2018-01-22 18:40 ` [PATCH v10 16/18] ovl: Fix ovl_getattr() to get number of blocks from lower Vivek Goyal
2018-01-22 18:40 ` [PATCH v10 17/18] ovl: Do not expose metacopy only upper dentry from d_real() Vivek Goyal
2018-01-22 18:40 ` [PATCH v10 18/18] ovl: Enable metadata only feature Vivek Goyal
2018-01-24 9:05 ` [PATCH v10 00/18] overlayfs: Delayed copy up of data Miklos Szeredi
2018-01-27 16:38 ` 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=20180123141357.GD2755@redhat.com \
--to=vgoyal@redhat.com \
--cc=amir73il@gmail.com \
--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