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