Re: handling NFSERR_JUKEBOX
Pete Wyckoff (firstname.lastname@example.org)
Fri, 13 Jul 2001 10:06:50 -0400
> To save you looking the key point is:
> >Not sure. Is there a way that the server can say, "I got your request,
> >but I'm too busy now, try again in a little bit." ??
> Isn't this what NFSERR_JUKEBOX is for?
> AFAIK, the protocol goes something like this:
> 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.
> It seems that what the linux client is doing is returning error 528
> to the user program (cp is giving this error message). From
> #define EJUKEBOX 528 /* Request initiated, but will not complete
> before timeout */
> This is wrong because the nfs file system is hard mounted in my case
> - there is no timeout.
> While it would be nice to do a perfect solution, it looks like
> a quick fix is to just ignore NFSERR_JUKEBOX from the server.
The comment is incorrect. Take a look at the RFC for NFSv3. There is
no duplicate request sent from the client for a JUKEBOX-supporting
server. The first request is satisfied by the return of EJUKEBOX, after
which it is up to the client to re-request the file. Ignoring it is not
an option because the request is terminated; a retry does not make
sense. A new request must be initiated by the client later.
Take a look at the nfs sourceforge mailing list. There's a long thread
about this in the context of a Solaris HSM server. I wrote a patch to
try to do the right thing on a linux client, but it is not perfect for
many reasons: http://devrandom.net/lists/archives/2001/6/NFS/0135.html
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/