Re: [patch 4/8] fs, exportfs: Add export_encode_inode_fh helper

On 08/16/2012 06:03 PM, James Bottomley wrote:

On Thu, 2012-08-16 at 17:54 +0400, Cyrill Gorcunov wrote:

quoted

On Thu, Aug 16, 2012 at 02:50:19PM +0100, Al Viro wrote:

quoted

On Thu, Aug 16, 2012 at 05:47:06PM +0400, Pavel Emelyanov wrote:

quoted

On 08/16/2012 05:43 PM, Al Viro wrote:

quoted

On Thu, Aug 16, 2012 at 04:38:14PM +0400, Cyrill Gorcunov wrote:

quoted

Hi Bruce, thinking a bit more I guess using general encode_fh is not that
convenient since it operates with dentries while our fdinfo output deals
with inodes. Thus I should either provide some new encode_fh variant
which would deal with inodes directly without "parents". Which doesn't
look for me anyhow better than the new export_encode_inode_fh helper.

Huh?  You do have dentries, for crying out loud...

Sometimes we don't -- the inotify thing gets an inode only.
Unlike other notifies that have dentries at hands...

What's wrong with saying "we don't support idiotify"?

Al, we need some way to restore inotifies after checkpoint.
At the very early versions of these patches I simply added
dentry to the inotify mark thus once inotify created we always
have a dentry to refer on in encode_fh, but I'm not sure if
this will be good design.

Actually, I was about to suggest this.  This can be done internally
within fs/notify without actually modifying the syscall interface, can't
it, since they take a path which is used to obtain the inode?  It looks
like the whole of the inotify interface could be internally recast to
use dentries instead of inodes.  Unless I've missed something obvious?

This will change the observable by userspace behavior. Various apps inotify a
file, then rename/unlink/link it or do tricks with mounts container the file.
And it works one way if the dentry+mount reference is 0 (now) and some other
way if it's not (after the proposed change).

The dentries-related behavior is especially bad on NFS with its silly-renames
decisions based on dentry reference counters. The mount-related one is bad in
general.

I'm saying this, because we were facing such problems at approx. once-a-week
rate when we did this in OpenVZ :(

James

Thanks,
Pavel