Re: [PATCH 3/9] ovl: Provide a mount option metacopy=on/off for metadata copyup

[Vivek Goyal <vgoyal@redhat.com>]

On Wed, Oct 11, 2017 at 07:29:38PM +0300, Amir Goldstein wrote:

[..]
> >
> > Anyway, I did not understand what's the problem with borken upper
> > hardlinks when index=off. If two upper hardlinks (broken), can
> > point to same ORIGIN on lower, they will just copy up same data.
> >
> > IOW, it does not seem to be more broken then what it is now just
> > becase of metadata copy up or because of both upper pointing to
> > same ORIGIN? What am I missing.
> >
> It is not broken now because we intentionally do NOT set origin when
> copying up lower hardlinks and index is disabled.
> You must not break this rule, so instead you can avoid metacopy for
> lower hardlinks when index is disabled.

Hi Amir,

Ok, I am open to change it so that if index=off, lower hardlinks are not
copied up metadata only.

But please help me understand that what *additional* thing breaks if origin
is set when index=off. 

Say lower has a file foo.txt and another hard link foo-link.txt.
(say index=off, metacopy=off).

Say, I open foo-link.txt for WRITE, and it gets copied up. Now there is
no link between foo-link.txt and foo.txt and if a user opens foo.txt for
READ, it does not see updates to foo-link.txt. So this is the broken
behavior of hardlinks with index=off, as of today.

Now I go back to original state and this time do same operation with
(indxex=off, metacopy=on). Then "chown foo-link.txt" will only copy
metadata and set origin to lower file. Say I also chown "foo.txt", that
will do the same thing. Now both foo.txt and foo-link.txt will have
ORIGIN pointing to same lower inode. If any of the file is opened for
WRITE, data will be copied up from same origin.

So setting same ORIGIN on two upper files, does not seem to break anything
additional, AFAICS. What am I missing.

Vivek