Messages in this thread | | | Date | Sun, 7 Sep 2003 12:03:40 -0400 | Subject | Re: NFS client problems in 2.4.18 to 2.4.20 | From | Trond Myklebust <> |
| |
>>>>> " " == Jamie Lokier <jamie@shareable.org> writes:
>> This is not an issue for tapes, etc. NFS has an alternative >> mechanisms for dealing with this in the form of the >> NFSERR_JUKEBOX error.
> Oh, cool. Perhaps the server should send these automatically, > when I/O operations are taking a little bit too long?
Yes. Needs a patch to knfsd, but would be very useful for people that want to export tapes, CD exchangers, etc...
>> By setting 'retrans=6' (5 + 1 to compensate for the bug), >> therefore, people can ensure that we retry for at least 6 >> seconds before timing out. The question is: is this an adequate >> default?
> That would be a big improvement. I take it you have > effectively clamped the retransmit time at a minimum of 1/10 > second, then? (I didn't understand what you meant earlier).
Yes. When we calculate the timeout value, we add the estimated error*4 to the estimated round trip time. I've set a floor on the former value so that the minumum timeout will be 1/10second.
> Last time I used a soft mount, I was seeing the first > retransmit after some time smaller than a millisecond. (I > don't remember, but 0.1ms sounds about right). If that is the > retransmit time, then retrans=6 won't be enough - retrans=16 > would be needed. I don't think a good correct retrans=xxx > setting should depend on the network like that. Setting a > minimum retransmit time is one way to fix that.
It is already in 2.6.0. I'm expecting to put it into 2.4.23 too, but I want to know that this (together with a patch to 'mount' to change the retrans default) really does solve the problem for people...
Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |