Re: [PATCH v10 07/18] ovl: Add mechanism to create a chain of origin dentries

[Vivek Goyal <vgoyal@redhat.com>]

On Tue, Jan 30, 2018 at 10:05:08PM +0200, Amir Goldstein wrote:
> On Tue, Jan 30, 2018 at 10:03 PM, Amir Goldstein <amir73il@gmail.com> wrote:
> > On Tue, Jan 30, 2018 at 9:33 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> >> 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.
> >>
> >> Hi Amir,
> >>
> >> What about the case when we have upper and one middle metacopy. As of top
> >> most lower is the ORIGIN for upper. Should we retain that top most lower
> >> ORIGIN as well as lower most data. Or just retain lower most data and
> >> use that as ORIGIN.
> >>
> >
> > Not sure I follow.
> > IIUC, the longest possible chain is lowerstack size 2:
> > upper -> metadata ORIGIN -> data ORIGIN
> >
> 
> If you are wondering if we could drop the metadata ORIGIN,
> I think we need it at least for constant and persistent st_ino.

Right, I was wondering can be drop metadata ORIGIN and just live with
data ORIGIN.

My initial impression is that constant and persistent st_ino can be
achieved using just data ORIGIN alone as well. But I might be missing
some finer detail.

Vivek