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@xxxxxxxxxxxxxxx
