> 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 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
