Hi- One of our testers stumbled on an interesting phenomenon yesterday. He purposely caused a client to run out the grace period clock during lock recovery on an NFSv4.1 mount. He did this by taking thousands of two-byte locks on the same file, and then rebooting his server. The client detects the reboot and starts reclaiming locks. When the grace period expires, the server replies NO_GRACE to the current LOCK(reclaim). The client responds with RECLAIM_COMPLETE, then goes into a hard TEST_STATEID loop. If I understand the recovery logic, this is trying a TEST_STATEID on every lock that was held by the client. The thing is, all the locks use the same stateid, since they are on the same file. So the client is sending TEST_STATEID with the same stateid argument over and over and over. All work on the client's mount point stops until that loop completes (which it eventually does). Is there room for some optimization here? Performing one TEST_STATEID per lockowner/FH pair is probably better, but I'm not clear on how post-grace period recovery is supposed to work. -- Chuck Lever -- 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
