On Thu, Oct 14, 2010 at 10:17:21AM -0400, Trond Myklebust wrote: > On Thu, 2010-10-14 at 10:00 -0400, J. Bruce Fields wrote: > > So, on the server side... As Trond says, we'd like to know which > > clients have been active recently. (In the v4 case, the lease gives > > that a precise meaning. In the v2/v3 case, I suppose we just pick a > > number to use as a timeout. We could use the v4 lease time.) It's only > > the kernel that knows which clients have been active recently. So we'd > > need a way for the client to export that information to userspace. > > > > Greg's per-client statistics might be a good starting point: > > > > http://thread.gmane.org/gmane.linux.nfs/25537/focus=25534 > > > > Though that's just per-ip address, which isn't ideal for v4. (In the v4 > > case the client identifier/owner allows us to distinguish e.g. between > > multiple clients on the same machine, or behind the same NAT.) I think > > that wouldn't be hard to fix. (Maybe just add on some ascii-escaped > > representation of the clientid to the end of the same line?) > > Relying on the lease isn't good enough. While an NFSv4.1 client is > indeed required to renew its lease before it can do any useful work, an > NFSv4.0 client is only required to establish a lease in order to OPEN a > file. > The Linux NFS client will, for instance, defer establishing a lease > until first open, and will stop renewing that lease when nobody is > holding any open file state. Good point, thanks. --b. > One alternative to using the lease state is to use the TCP connection > state and/or the TCP/UDP port number. That's pretty much what we use to > distinguish separate NFS clients in the replay cache anyway... -- 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
