> -----Original Message----- > From: linux-nfs-owner@xxxxxxxxxxxxxxx [mailto:linux-nfs- > owner@xxxxxxxxxxxxxxx] On Behalf Of Steve Dickson > Sent: Friday, February 15, 2013 4:46 PM > To: J. Bruce Fields > Cc: linux-nfs@xxxxxxxxxxxxxxx > Subject: Re: V4 unmount causes a GETATTR > > > > On 15/02/13 13:25, J. Bruce Fields wrote: > > On Fri, Feb 15, 2013 at 10:46:00AM -0500, Steve Dickson wrote: > >> Hello, > >> > >> I have not tracked down as to the exact reason, but it appears umount > >> of v4 file system cause the directory to be revalidating causing the > >> GETATTR. > >> > >> Is this revalidation really necessary on an unmount? > > > > I don't know, maybe not. But even if it's not, there are other things > > (like cleaning up state) that the client will likely try to do on > > unmount. In the presence of delegations it could have dirty data that > > it's required to write back even if applications don't currently hold > > any open files. > Understood with dirty data... but what I as seeing was a v4 mount and then a > reboot with no activity on the mount point... > > > > > So I don't think we can promise umount will work without the network. > Again with open files (aka activity on the mount point) I agree but with no > activity or open files, I'm think that GETATTR is simply not necessary... You'd need to add a lookup intent specifically for umount. Otherwise the filesystem will not be able distinguish between path lookups for umount and other activity. Also note that "no activity or open files" is no guarantee that you won't be holding delegations or pNFS layouts to return; you may still see hangs. Cheers, Trond -- 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
