Subject: [nfsv4] Volatile File Handle Questions

From: Matthew Treinish <[email-masked]>
Date: Mon, 9 Apr 2012 14:55:43 -0400

I've recently been working on adding volatile file handle support to the Linux
client. During this work I've had a few issues and ambiguities come up with
the spec regarding recovery and VFH in general. I was hoping I could get some 
clarification.

For recovery, on receiving a NFS4ERR_FHEXPIRED error I have the client perform
a lookup using the directory's handle and the name. If this operation also 
fails with NFS4ERR_FHEXPIRED I recurse up a directory until either the lookup 
succeeds or I hit the root of the mount. However, in the RFC for VFH recovery 
it says:

        For volatile filehandles, most commonly the client will need to store
        the component names leading up to and including the filesystem object
        in question.  With these names, the client should be able to recover
        by finding a filehandle in the name space that is still available or
        by starting at the root of the server's filesystem name space.

So I'm unclear if this method of recovery is compliant with the RFC, or if I
should start at the root with PUTROOTFH and perform LOOKUPS on every file in a 
depth first approach until I get to the new filehandle that originally returned 
the NFS4ERR_FHEXPIRED error?

Along this line I was also unsure of what the client is supposed to do if the it
can't recover from NFS4ERR_FHEXPIRED. The spec just states:

        If possible, the client SHOULD recover from the receipt of an
        NFS4ERR_FHEXPIRED error.

If the client is unable to recover from an expired filehandle for some reason
is there a procedure that it should take, or should it just treat the failed
recovery like it would treat NFS4ERR_STALE?

There is the race condition, which has been brought up before, with renames and 
deletes during recovery. Is the client just supposed to assume that the 
returned filehandle refers to the same file from before it expired. Or, are 
there any steps that the client should take to ensure that the file handle 
refers to the same file. The only mechanisms I could think of wouldn't be 
exhaustive and may return false positives. (i.e. comparing attributes before and
after recovery)

I think these issues are something that should be addressed before I continue 
with the implementation for the Linux client. Although, there a few other      
clients out there that implement volatile filehandles (AIX, z/OS, Solaris that 
I know of) does anyone know how they tackled these issue?

Thanks,

Matt Treinish