This is a complete network trace between the client and server. So this issue only happens on Kernels 3.9.6 and newer. I did not have this problem with Kernel 3.8.13 nfs-utils-1.2.3-36 (from Redhat) was used w/ all kernel versions. The mount command includes option "noac". I assume when mounts do not include this option, the sending of the trailing getattr is suppressed since the client cached its attributes. Let me know if you need anything else. Christopher Vogan Dept. W98 NFS Development & Test From: "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> To: Steve Dickson <SteveD@xxxxxxxxxx>, Cc: Christopher T Vogan/San Jose/IBM@IBMUS, "linux-nfs@xxxxxxxxxxxxxxx" <linux-nfs@xxxxxxxxxxxxxxx> Date: 06/26/2013 02:25 PM Subject: Re: NFSERR_STALE on umount with 3.10.0.RC5 kernel On Wed, 2013-06-26 at 15:20 -0400, Steve Dickson wrote: > > On 18/06/13 15:59, Myklebust, Trond wrote: > >> -----Original Message----- > >> From: Christopher T Vogan [mailto:cvogan@xxxxxxxxxx] > >> Sent: Tuesday, June 18, 2013 3:56 PM > >> To: Myklebust, Trond > >> Cc: linux-nfs@xxxxxxxxxxxxxxx > >> 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.... That's the order that will cause the result Christopher is seeing: first a UMNT call, then a lookup/revalidate as part of the umount() system call. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com
Attachment:
reddy4-umount.pcap.bz2
Description: Binary data
