Re: ETIMEDOUT in nfsd?

["J. Bruce Fields" <bfields@fieldses.org>]

On Thu, Aug 05, 2004 at 12:26:08PM +1000, Greg Banks wrote:
> On Wed, Aug 04, 2004 at 10:13:46AM -0400, J. Bruce Fields wrote:
> > So from the point of view
> > of the NFS server code, it does look like a retry, but the NFS client
> > isn't involved--the server rpc code did the retry on its own.
> 
> Aha...I see now.
> 
> > This is only right if upcalls are done before you've done anything
> > non-idempotent, which makes it hard to handle NFSv4 compounds
> > correctly.
> 
> Ouch, this is not a good assumption, especially considering servers
> rebooting and cache timeouts.

I don't see the problem you're referring to.  I don't believe that in
either case these internal replays add any problems that we don't
already have, but perhaps I'm missing something.

> > > Why not send EJUKEBOX to the client, and let it manage retry using a
> > > retry strategy designed for a slow server instead of the one designed
> > > for lossy networks?
> > 
> > That might mean returning EJUKEBOX on a lot of common operations (e.g.
> > on the first rpc request from a new client), when the server usually
> > could have replied very quickly.
> 
> Potentially.  But, in your experience do idmapper upcalls proceed quickly?

It's a good question; it would be interesting to measure them sometime
with a variety of different configurations (local /etc/passwd, ldap,
etc.), but we haven't gotten around to that yet.

--Bruce Fields


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs