Re: overlayfs NFS export

[Trond Myklebust <trondmy@primarydata.com>]

On Fri, 2017-04-07 at 17:28 +0200, Miklos Szeredi wrote:
> On Fri, Apr 7, 2017 at 4:57 PM, Trond Myklebust <trondmy@primarydata.
> com> wrote:
> 
> > What is the problem you are trying to solve?
> 
> The problem is getting a persistent file handle for overlayfs files.
> 
> One idea suggested by Viro is to create a dummy inode on the upper
> layer whenever we look up a dentry in the overlay filesystem.  Then
> we
> have an inode number reserved for the file if it needs to be copied
> up. This solves the file handle problem, since we can generate a path
> from the file handle and from there get the original lower layer file
> (assumes the file handle has the parent handle encoded as well).  If
> the file is copied up, the file is no longer assiciated with the
> lower
> layer, we just need to use the upper inode, this works too.  And also
> files created on the upper work fine.
> 

Why do you need the parent directory to be encoded as well? Doesn't
fh_to_dentry() suffice?

The thing is that for all namespace related operations (mkdir(),
rmdir(), open(O_CREATE), unlink,...) the client will supply the parent
filehandle, so those operations should not normally suffer.

The only operation that would be a problem is when you have to copy up
a regular file, but for that case overlayfs needs to generate dentries
for _all_ hardlinks to that file, in the upper layer, no?

> The only little problem is that we are creating lots of inodes on
> disk
> and memory that until now we haven't.  Currently overlayfs only
> modifies upper layer if there's a good reason to believe that there
> is
> really going to be modification (e.g. when file is opened for write).
> 
> The alternative is generate file handle from lower file (if on lower)
> and from upper file (if on upper).   The issue is if the file is
> copied up and goes from lower to upper.  In that case we need to find
> the upper file from the handle generated from the lower file.   This
> works as long as the upper file hasn't been renamed, same way we
> found
> the lower from the upper Viro's scheme: generate path from lower file
> handle and look up in overlay.  When copied up file is renamed, this
> doesn't work anymore, so we need a mapping from lower-handle to
> upper-handle.
> 
Generating filehandles from the namespace is a nightmare. It only works
if you have strict non-POSIX-compatible rules about not being able to
modify the parent of a subtree if there is a file in use in that
subtree. You can therefore make it work if the underlying filesystem is
something like NTFS, but not if you want POSIX semantics.

-- 
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@primarydata.com