On Fri, 2010-03-19 at 16:22 -0400, Chuck Lever wrote: > On 03/14/2010 04:40 PM, Guillaume Rousse wrote: > > Le 19/01/2010 17:37, Chuck Lever a écrit : > >> As far as I understand it, "-l" means the kernel will do the local > >> detach from the system's file name space whenever there are no more > >> users (ie entirely asynchronously). I don't think umount2(MNT_DETACH) > >> indicates whether the kernel was able to completely unmount that file > >> system by the time the call returns, so there's perhaps no way for > >> umount.nfs to know whether it should send the UMNT request. If the > >> server is slow or unresponsive, that file system won't be unmounted > >> until long after the umount.nfs command has exited. > >> > >> This shouldn't be much of a big deal, since the server's rmtab is > >> "ornamental" according to the man page. No one should rely on it being > >> accurate. > >> > >> A possible way to fix this is to have the kernel send the UMNT. > > It makes sense, but it doesn't seem to trigger much interest :) > > > > Should I open a bug somewhere, to ensure the issue won't be forgotten ? > > You might consider filing a bug in the NFSv4 bugzilla on linux-nfs.org. > 1) What does this have to do with NFSv4? 2) I don't have to do lazy umounts in order to confuse umount.nfs. Consider mount -t nfs foo:/bar /mnt1 mount --bind /mnt1 /mnt2 umount /mnt1 umount /mnt2 3) Even the kernel doesn't know what to do in all cases, because it doesn't know whether or not a mount rpc call was sent or not for each mountpoint that you do a 'umount /mnt' on. Consider the case where you do a clone(CLONE_NEWNS), and then the user does 'umount /mnt' in _one_ of those namespaces. IOW: Please just accept that this is a feature, not a bug. Nobody promised you that the mountd statistics would be 100% accurate, and we're certainly not going to waste time trying to make it so. 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
