From: rick@snowhite.cis.uoguelph.ca
Date: 07/18/02-09:50:04 AM Z
From: rick@snowhite.cis.uoguelph.ca Date: Thu, 18 Jul 2002 10:50:04 -0400 (EDT) Message-Id: <200207181450.KAA21081@snowhite.cis.uoguelph.ca> Subject: NFS over TCP stuff Hi, (Sorry, I figured these were just random comments, so I didn't bother attributing comments to authors, since they were in several different messages.) > As a user myself, I have been unaffected by these issues as far as I > know. As a developer, they constitute rules which govern my > implementation, but these issues are never visible above either the RPC > or the NFS levels. They can not be or the implementation is broken. As a sysadmin, I can tell you users get very irritated by "NFS Server not responding". (I don't know how many times I've said, "No, it's not broken, the server is just slow".:-) However, from an industry point of view, having the NFS server collapse horribly is a good thing. That's what encourages customers/users to fork over big bucks for bigger servers:-) > Not necessarily. Currently, servers can shed load by dropping requests. > A requirement to transmit NFSERR_DROPPED replies would be more work. The problem is that, when a server silently drops a request, it doesn't provide any feedback to the client. As such, the client keeps retrying and the server keeps dropping. To me, this can result in "more work". > You can't know the link state with any certainty until you transmit > something. The question is: do you transmit some kind of null > request, or the original request ? SO_KEEPALIVE was all I've ever used (in both directions on the connection) and it did work, albiet taking a long time sometimes (15minutes in worst case?). > I believe current practice with most clients is to increase the > timeout significantly when TCP is used - since we assume TCP > will do a better job of handling dropped/lost packets. And if the server ever does drop a request, this means a long wait and irritated users. (In another post, 30sec wasn't long enough, so wait one minute or two minutes or...) I never did put a retransmit in my BSD code over TCP (except after a reconnect) and I never heard complaints. (I don't know if the BSD descendants ever added it or not?) Way back when, I envisioned a server that wouldn't drop requests and a client that would only retransmit after a reconnect. I can't remember if I discussed this (12 years ago) in "Lessons Learned Tuning 4.3Reno..." along with the other NFS over TCP stuff. Have fun with it, rick
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:58 AM Z CST