Re: [PATCH/RFC v3 00/10] Volatile File Handle Client-side Support

[Matthew Treinish <treinish@linux.vnet.ibm.com>]

On Mon, Mar 05, 2012 at 03:26:41PM -0500, Matthew Treinish wrote:
> 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 Linux server to output NFS4ERR_FHEXPIRED instead of
> NFSERR_STALE.
> 
> 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.
> 
> The 2 key changes in this iteration are fixing recovery from getattr and 
> adding support for VFH during migration/replication. Recovery from getattr is
> accomplished by taking the file handle and searching for a match in the dcache.
> I couldn't find a better way to get a dentry or inode from the filehandle,
> since nfs_fhget() needs the fattr for the file. (Which clearly isn't accessible
> or up to date if getattr is being called)
> 
> For migration/replication, if FH4_VOL_MIGRATION is set in FH_EXPIRE_TYPE, then
> after the client migrates or replicates to another server we can assume that
> all the file handles have expired. nfs4_vfh_replication() will traverse all
> the dentries in the dcache for the NFS mount and perform a nfs4_proc_lookup()
> on them to refresh the file handle. However, the VFH migration/replication 
> recovery function is currently not being used. When migration and replication
> are added to the tree I will add patches that will call it at the appropriate 
> time. 
> 
> Also, when used for replication and migration, volatile file handles allows 
> the client to switch between 2 servers that have file synced exports
> but different filesystems. For example, if 2 read-only servers are synced
> using rsync and then remain static the client should have no issues switching
> between the servers with volatile file handles.
> 
> Volatile file handle support fulfills an actual need. The z/OS NFS server
> currently uses volatile file handles and the Linux client can't handle them
> preventing those who use the z/OS server from connecting with a Linux client.
> Additionally, other clients, such as Solaris, AIX, z/OS, and possibly Windows,
> can handle volatile file handles. So I think including support is necessary 
> despite the flaws in the spec that were previously discussed. This is why I 
> included a mount option that disables the recovery routines by default, so 
> there is no risk to the user who doesn't understand what the potential issues
> are when recovering from volatile file handles.
> 
> v3:
> - Fixed recovery from nfs4_proc_getattr() which is only passed a file handle
> - Added support for migration/replication file handle recovery
> 
> v2:
> - Added rpc_cred passing to the vfh lookup and added handling of access errors
>   on the lookup
> 
> Matthew Treinish (10):
>   New mount option for volatile filehandle recovery
>   Add support for FH_EXPIRE_TYPE attribute.
>   Save root file handle in nfs_server.
>   Store root dentry in server object
>   Store objects in nfs4_exception to be used during FHEXPIRED recovery.
>   Add nfs4_vfh_getdentry() for getattr recovery.
>   Add VFH FHEXPIRED recovery functions.
>   Perform recovery on both inodes for rename.
>   Added error handling for NFS4ERR_FHEXPIRED
>   VFH recovery from a replication/migration event.
> 
>  fs/nfs/client.c           |    3 +
>  fs/nfs/getroot.c          |    8 +
>  fs/nfs/nfs4_fs.h          |    5 +
>  fs/nfs/nfs4proc.c         |  422 +++++++++++++++++++++++++++++++++++++++++----
>  fs/nfs/nfs4xdr.c          |   27 +++
>  fs/nfs/super.c            |    7 +
>  include/linux/nfs_fs_sb.h |    3 +
>  include/linux/nfs_mount.h |    1 +
>  include/linux/nfs_xdr.h   |    1 +
>  9 files changed, 447 insertions(+), 30 deletions(-)
> 
> -- 
> 1.7.4.4
> 

Did anyone get a chance to take a look at these patches? I'd appreciate some
feedback and opinions on it.

Thanks,

Matt Treinish