nfs client hanging

[J. Bruce Fields]

On Wed, Jul 02, 2008 at 01:19:17PM -0400, Trond Myklebust wrote:
> On Wed, 2008-07-02 at 14:00 +0200, Guillaume Rousse wrote:
> > Actually, I spoke too fast, the problem also occurs with files hosted on 
> > the linux server, with a different scenario:
> > - the connection is still present when the hang occurs
> > - rpc.idmapd seems to have crashed (no trace in the logs, tough, as 
> > verbosity was set to 0)
> > 
> > Full client (rpc + nfs flags) and servers  (rpc + nfsd flags) logs are 
> > available at http://www.zarb.org/~guillomovitch/{client,server}.log.
> > 
> >  From what I understand, this is a normal revalidation operation:
> > Jul  2 04:35:00 chatelet kernel: NFS: revalidating (0:15/7322625)
> > Jul  2 04:35:02 chatelet kernel: NFS: nfs_update_inode(0:15/7322625 ct=2 
> > info=0xe)
> > Jul  2 04:35:02 chatelet kernel: NFS: (0:15/7322625) revalidation complete
> > 
> > Starting from 5:13, revalidation on this inode doesn't complete anymore, 
> > which seems to imply the problem occurs between 04:35:02 and 05:13:47:
> > Jul  2 05:13:47 chatelet kernel: NFS: revalidating (0:15/7322625)
> > Jul  2 08:26:13 chatelet kernel: NFS: revalidating (0:15/7322625)
> > 
> > But I don't find anything really suspicious :(
> 
> If the idmapper was crashed, then that is quite sufficient to explain
> your trouble. The above GETATTR calls rely on the idmapper to translate
> NFSv4 names into uids and gids, and will hang if it is not responding.

And figuring out why idmapd crashed would be a really good thing to do
in any case....  So that's the question to work on, I think.

--b.