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 -- 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
