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