This patch series implements client side support for volatile file handle recovery (RFC 3530 section 4.2 and 4.3) with walk back using the dcache. To test the client you either need a server that supports volatile file handles or you can hard code the server to output NFS4ERR_FHEXPIRED instead of NFSERR_STALE. (See the last patch in the series) The approach used here for recovery is to perform lookups for each file handle that receives a FHEXPIRED error. If the lookup also fails with FHEXPIRED using the dcache, it will recursively walk back to the root of the mount, and recover that using get_root. Simple testing has shown that this approach works and will correctly recover from a FHEXPIRED error code. However, the current implementation uses d_obtain_alias if a nfs4_proc function is only given an inode. When hardlinks are involved, this results in getting a path, but not necessarily a path which the user has access, which might lead to permission issues. Since the RFC did not mandate how to recover from FHEXPIRED I would assume this approach solves majority of the generic use cases, but, I think that some more discussion is needed on this topic. Also, considering that this is my first kernel patch set, I think it definitely needs review. Matthew Treinish (7): New mount option for volatile filehandle recovery Added support for FH_EXPIRE_TYPE attribute. Add VFS objects from nfs4_proc calls into nfs4_exception. Save root file handle in nfs_server. Added VFH FHEXPIRED recovery functions. Perform recovery on both inodes for rename. Added error handling for NFS4ERR_FHEXPIRED fs/nfs/client.c | 3 + fs/nfs/getroot.c | 7 ++ fs/nfs/nfs4_fs.h | 2 + fs/nfs/nfs4proc.c | 245 +++++++++++++++++++++++++++++++++++++++------ fs/nfs/nfs4xdr.c | 27 +++++ fs/nfs/super.c | 6 + include/linux/nfs_fs_sb.h | 2 + include/linux/nfs_mount.h | 1 + include/linux/nfs_xdr.h | 1 + 9 files changed, 265 insertions(+), 29 deletions(-) -- 1.7.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
