Hey Trond,

Marc Eshel wrote:

>The problem is that after the NFS sever machine reboots its statd sends a
>notification to all NFS clients that had locking activity but the clients
>fail to reclaim their locks.
>  
>
Well it appears things are a bit broken. Here is a client side patch that
enables the client to reclaim locks on a rebooted server.

The two main issues were nlm4svc_decode_reboot() not setting
the protocol which cause the nlm_host structure not to be found
and two, making nlmclnt_reclaim() retry when the portmapper was up
but lockd had not made it yet.... I also fixed a debugging
statement and well as added a couple... that I found useful....

Now the reclaim retry code currently retries forever in an
interruptible loop waiting for lockd to come up. This may or
may not be a good idea, but the client should not make any
assumptions about the health of the server, to I'm not sure there
is anything else that can be done....

Unfortunately this reclaim code freaks out the linux server, causing it
to send two back-to-back messages (both using the same xid) that
fails and then grant the lock.... It seems the dentry_open() call
(in nfsd_open()) is returning 30000 error value. Its not clear why or
what a 30000 value means....  I'm still looking in to that, but this code
was tested with both a Neapps filer and Solaris 10 server which seem
to work fine..

Comments? 

SteveD.