Re: NFS client hangs after server reboot

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

On Fri, Apr 12, 2013 at 11:19:39AM +0200, Bram Vandoren wrote:
> > Just to clarify/correct what I posted yesterday...
> > The boot instance is the first 4 bytes of the clientid and the first
> > 4 bytes of the stateid.other. (Basically, for the FreeBSD server, a
> > stateid.other is just the clientid + 4 additional bytes that identify
> > which stateid related to the clientid that it is.)
> >
> > Those first 4 bytes should be the same for all clientids/stateid.others
> > issued during a server boot cycle. Any clientid/stateid.other with a
> > different first 4 bytes will get the NFS4ERR_STALE_CLIENTID/STATEID
> > reply.
> 
> Thanks for the clarification. I tried to reproduce the problem using a
> test setup but so far I didn't succeed. It's clearly not a problem
> that happens all the time. Also not all the clients lock up in the
> production system. Only a fraction of them (~ 1 in 10).
> 
> I checked the packets again. The Stateid in a read operation is:
> 9a:b6:5d:51:bc:07:00:00:24:23:00:00
> The client id:
> af:c1:63:51:8b:01:00:00

Yeah, so 9a:b6:5d:51 and af:c1:63:51 if you take them as little-endian
integers look like pretty reasonable recent dates in unix time, so that
agrees with Rick's description of the FreeBSD server's stateid and
clientid.

So that does sound like the client failing to toss an old stateid after
renew?

--b.

> 
> It seems we ended up with a stale stateid but with a valid client id.
> 
> I am going to do some more tests with mutiple clients to try to
> reproduce the problem. If that doesn't succeed I try to get the data
> from the production server when we have to reboot it next time (but
> this can take a while).
> 
> Thanks,
> Bram
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html