On Tue, Apr 09, 2013 at 05:51:40PM +0200, Bram Vandoren wrote: > Hello, > we have a FreeBSD 9.1 fileserver and several clients running kernel > 3.8.4-102.fc17.x86_64. Everything works fine till we reboot the > server. A fraction (1/10) of the clients don't resume the NFS session > correctly. The server sends a NFS4ERR_STALE_STATEID. The client sends > a RENEW to the server but no SETCLIENTID. (this should be the correct > action from my very quick look at RFC 3530). After that the client > continues with a few READ call and the process starts again with the > NFS4ERR_STALE_STATEID response from the server. It generates a lot of > useless network traffic. 0.003754 a.b.c.2 -> a.b.c.120 NFS 122 V4 Reply (Call In 49) READ Status: NFS4ERR_STALE_STATEID 0.003769 a.b.c.2 -> a.b.c.120 NFS 114 V4 Reply (Call In 71) RENEW I don't normally use tshark, so I don't know--does the lack of a status on that second line indicate that the RENEW succeeded? Assuming the RENEW is for the same clientid that the read stateid's are associated with--that's definitely a server bug. The RENEW should be returning STALE_CLIENTID. --b. -- 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
