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