On Tue, Mar 16, 1999 at 12:28:19PM -0800, Bill Studenmund wrote:
> > 
> > Isn't this what NFSERR_JUKEBOX is for?
> 
> Not being familiar with the error, I'm not sure. :-)
> 
> > Client sends a request.
> > Server starts loading tape/optical disk/whatever.
> > Client resends request.
> > Server notices that this is a repeat of an earlier request which is already
> > in the "slow queue", and replies NFSERR_JUKEBOX (= "be patient, I'll send
> > the response eventually").
> > Client shuts up and waits.
> > Server completes request and sends response to client.
> 
> Ick. That's not quite the protocol I was hoping for.
> 
> I was hoping for something more like:
> 
> Client sends a request.
> Server sees it can't service
> Server tells client to try again later
> Client keeps request around, and sleeps on it.
> Client tries again.
> Server sees if it can service. If not, server says try later.

This is, in fact, what is supposed to happen.. NFSERR_JUKEBOX (for some
reason called TRYLATER in our code; presumably because of a similarly
named NQNFS construct) is the right one to use, and does, or is supposed
to do, exactly what you want. The client should wait for a while and
try again, using the same XID. Should've thought of that sooner..
thankfully Roger pointed it out.

The NetBSD client should do exponential backoff in this case. It's
actually a piece of code that probably never was tested.. but
it's simple, nothing much can go wrong (famous last words ;-))

- Frank