On Fri, 2017-04-07 at 18:58 +0300, Amir Goldstein wrote: > On Fri, Apr 7, 2017 at 6:46 PM, Trond Myklebust <trondmy@primarydata. > com> wrote: > > On Fri, 2017-04-07 at 17:28 +0200, Miklos Szeredi wrote: > > > On Fri, Apr 7, 2017 at 4:57 PM, Trond Myklebust <trondmy@primaryd > > > ata. > > > 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? > > > > Put it simply, you encoded a file /mnt/A/b which is found at > /lower/A/b and when you later come with this handle, you need to > check not only that the original lower inode is not stale (trivial), > but also that there is no new file or whiteout at path /upper/A/b. > so you can do this by converting handle to path and then looking > up same in /upper. everything breaks when upper dirs get renamed... Only if the client asks you to lookup that file in that directory, in which case it will supply you with a filehandle for that directory. > > > 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? > > Needs to... but it bloody well doesn't. That's one of the hardest > issues. > > > > > > 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 > > You mean generating a path from filehandle? or generating a > filehandle > with parent so it can be reconnected? I mean if you encode the path in the filehandle, you're borked. The whole purpose of filehandles is to provide something that is independent of the path so that POSIX semantics can be provided. > > 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. > > > > This was overlayfs prior to v4.10. too bad we fixed it ;-) > > Amir. > -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx
