Re: NFSERR_STALE on umount with 3.10.0.RC5 kernel

[Steve Dickson <SteveD@redhat.com>]

On 18/06/13 15:59, Myklebust, Trond wrote:
>> -----Original Message-----
>> From: Christopher T Vogan [mailto:cvogan@us.ibm.com]
>> Sent: Tuesday, June 18, 2013 3:56 PM
>> To: Myklebust, Trond
>> Cc: linux-nfs@vger.kernel.org
>> Subject: Re: NFSERR_STALE on umount with 3.10.0.RC5 kernel
>>
>> The NFS server uses UMNT as a signal to remove the client from its mount
>> table. Also at this time the Server cleans up other information about the now
>> disconnected client.  Why would the client attempt to access the NFS server
>> once it has stated its going to unmount?  I do not see the point of the
>> GETATTR request after UMNT call.
> 
> As I said, the umount.nfs utility is doing the umount system call after UMNT, so the 
> client does a lookup of the umount path at that time.
> 
> IOW: This has nothing to do with the kernel. If you feel it is a bug, then please ask 
> SteveD to file a fix against nfs-utils.
> 
I just took a look at the umount code and it appears the UMNT call and 
umount() system call are being done in the correct order... 

The UMNT call is done in nfs_umount23() which is follow by either
mnt_context_do_umount() (if using the libmount code) or del_mtab()
which make the umount() system call....

Would it be possible to post a bzip2 binary network trace file so I can
poke around... something similar:
    tshark -w /tmp/data.pcap host <server>
    bzip2 /tmp/data.pcap

steved.