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. -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
