Re: NFS client problems in 2.4.18 to 2.4.20

[Trond Myklebust <trond.myklebust@fys.uio.no>]

>>>>> " " == 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