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
��.n��������+%������w��{.n�����{���w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
