That sounds useful - would the reacquire be transparent to the client apps holding the locks?
If so, then I could just issue that periodically...and so could the NetApp :-).
-----Original Message----- From: Dylan Northrup [mailto:northrup@loudcloud.com] Sent: 30 March 2002 19:46 To: Edward Hibbert Cc: toasters@mathworks.com Subject: Re: Freeing NFS locks
On Sat, 30 Mar 2002, Edward Hibbert wrote:
:=I have a situation where I have a host which is not pingable, but lock_dump :=shows it as having a lot of NFS locks active. := :=Two questions: :=- Is there anything I can do to free up the locks (just for that host)? :=- Why doesn't the filer spot that the host has died, and free the locks :=automatically?
There's an rpc call you can do to the filer to instruct it to free all locks and re-acquire them from hosts that are still responsive. You'll likely have to write a program to do this since I don't believe there is a utility that will allow you to do this already. You can get more information by looking at the NLM (Network Lock Manager) spec, particularly the NLMPROC4_FREE_ALL procedure.
The reason the filer doesn't know the host has died is because NFS is inherently stateless and the NLM tries to impose state on top of NFS. Because NFS is stateless, the only time the filer knows anything has changed is when the client communicates with it. If the client panics or halts without shutting down normally the filer doesn't know it's fallen off the map and holds the locks like it should waiting for a a communication that won't come until the host is rebooted or its network connectivity is re-established.
Hope this helps.