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

On Thu, Aug 16, 2012 at 03:41:52PM +0100, Al Viro wrote:

On Thu, Aug 16, 2012 at 06:15:53PM +0400, Cyrill Gorcunov wrote:

quoted

On Thu, Aug 16, 2012 at 02:03:00PM +0000, James Bottomley wrote:

quoted

quoted

quoted

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?

Well, after looking into do_sys_name_to_handle->exportfs_encode_fh
sequence more precisely it seems it will be easier to extend
exportfs_encode_fh to support inodes directly instead of playing
with notify code (again, if i'm not missing something too).
i'm cooking a patch to show (once it's tested i'll send it out).

Good luck doing that with e.g. VFAT...  And then there's such thing
as filesystems that don't have ->encode_fh() for a lot of very good

Wait, Al, it seems I messed up. If some fs has no encode_fh() implemented
the default encoding with FILEID_INO32_GEN_PARENT will be used for that.

reasons; just try to do that on sysfs, for example.  Or on ramfs,
for that matter...  And while saying "you can't export that over
NFS" seems to work fine, idiotify-lovers will screech if you try
to ban their perversion of choice on those filesystems.

	Cyrill