On Oct 12, 2010, at 4:50 PM, Jeff Layton wrote: > On Tue, 12 Oct 2010 16:34:45 -0400 > Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > >> >> On Oct 12, 2010, at 4:26 PM, Jeff Layton wrote: >> >>> On Tue, 12 Oct 2010 16:21:00 -0400 >>> Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> wrote: >>> >>>> On Tue, 2010-10-12 at 15:52 -0400, Jeff Layton wrote: >>>>> On Tue, 12 Oct 2010 15:44:09 -0400 >>>>> Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> wrote: >>>>> >>>>>> On Tue, 2010-10-12 at 15:18 -0400, Jeff Layton wrote: >>>>>> >>>>>>> I think the part that causes problems is having userspace do this. In >>>>>>> theory, if the kernel were in charge of sending the UMNT, then it's not >>>>>>> really a problem since it knows when to do it. If we have code that >>>>>>> sends a UMNT already, why not do a best-effort UMNT call from the >>>>>>> kernel when we tear down the sb? >>>>>> >>>>>> Purely for the pleasure of allowing the server to maintain inaccurate >>>>>> statistics about who is currently mounting what? I think not... >>>>>> >>>>>> You can get far more accurate results by replacing the MNT/UMNT state >>>>>> counter with a purely server-based scheme to track who accessed one or >>>>>> more files on each exported partition in the past 5 minutes or so. That >>>>>> would even work with NFSv4... >>>>>> >>>>> >>>>> True, but for better or worse, UMNT is part of the protocol. It seems >>>>> like we ought to do our best to implement it, even if it is >>>>> fundamentally flawed. >>>>> >>>> >>>> UMNTALL is part of the same protocol, and yet we have never implemented >>>> that. Just because something is documented, it doesn't mean we have to >>>> do it... >>>> >>>> The bottom line is that UMNT doesn't do what it advertises itself as >>>> doing, and so we should not waste space supporting it in the kernel. We >>>> shouldn't do so in userspace either. >>>> >>> >>> Fair enough. Like Chuck I don't have strong feelings about it, other >>> than seeing no need to continue shipping umount.nfs. >> >> Careful... we still need umount.nfs, which is a link to mount.nfs. Something in user space has to kick off local namespace changes, even if the server isn't affected. >> > > Most other filesystems don't need a umount helper. If there isn't one > present then /bin/umount takes care of the umount() call and cleaning > the entry out of /etc/mtab. > > My understanding was that umount.nfs only existed because it was needed > to handle the UMNT RPC. Without that, there's really no need for it. > > ...or am I overlooking something? umount.nfs still handles "users=" which has special behavior for NFS mounts, for example. Does that matter? -- chuck[dot]lever[at]oracle[dot]com -- 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
