Re: [PATCH 0/6] ovl: consistent_fd feature

[Amir Goldstein <amir73il@gmail.com>]

On Fri, Apr 7, 2017 at 12:56 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:
> On Fri, Apr 7, 2017 at 11:32 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:
>> On Thu, Apr 6, 2017 at 6:25 PM, Amir Goldstein <amir73il@gmail.com> wrote:
>
>> When renaming a lower/merged directory or lower non-directory, always
>> add back-redirect pointer to moved object pointing to original
>> location, as well as forward-redirect to whiteout at original location
>> pointing to new location.   Possibly could do both with file handle.
>> Whenever either is moved/created/removed pointers need to be updated.
>> Hard linking a copied up file would result in duplication of the
>> forward pointers.  Solves the nfs export case, since we can always
>> find new location of objects based on location on lower layer.
>
> This breaks when an ancestor of a forward-redirect is moved/removed.

Right. but may still be feasible to mix this idea with a linked list
of only renamed dirs (topology transformation info).

>
> A linked list would still work, but all these are bit fragile.  I feel
> it's better to keep this sort of info out-of-band.
>

My main concern with out-of-band metadata is that we will have to sync
this metadata and it is easier to think on metadata transactions in
terms of changes
that are natively bundled together with the original inode
modification by the fs.

For that matter, I like the forward/backward redirect by fh idea, because
affected inodes are most of the time already part of the metadata transaction.
Also, backward redirect should be by path (like it is now) so it is
agnostic for more
renames and forward redirect should be by fh for the same reason and so it
is agnostic to moved object remove as well.

This is interesting enough for me to play with as part of "promotion"
for redirect_fh,
so I may just try to sketch some rough POC for NFS export.

Come to think about it, NFS export of regular file don't need to
follow renames at all:
- The handle for a regular file is always the handle for the real
lower or upper inode
- To decode a handle, create an O_TMPFILE style overlay dentry, which
is not linked
  to any path in overlay, but has the _upperdentry/lowerstack setup
- This way, nfsd can open a read-only handle from the ancient past (why not...)
- Directory handles would have to use the lowermost inode
- To decode a directory handle we need either forward redirect pointers on any
  new object created on top of lower dir or maintain a linked list  and hash or
  all renamed dirs

Am I missing something?

Amir.