Re: statd simplified

[Steve Dickson <SteveD@redhat.com>]

Olaf Kirch wrote:

>So I sat down last week and dusted off some old ideas how to simplify
>NLM/NSM interaction quite a bit.
>  
>
Putting statd in the kernel I think  a good idea... Probably the only
reason it has not been done, is the fact, managing the state file from
the kernel is a real pain...

>The approach I implemented was to get rid of all the SM_MON/SM_UNMON
>calls completely. If lockd wants a remote host to be "monitored", simply
>add it's IP address to /var/lib/nfs/sm. This used to be statd's job,
>but there's no reason why we cannot do that in the kernel.
>  
>
Letting /var/lib/nfs/sm grow uncontrollably (i.e. not using SM_UNMON to
clean it up) may not be a good idea... Since users can't go in and clean 
in up by hand
(since they could be removing live state), there probably should be some
way to cleaned up (and up to date)

>In addition, lockd now understands a very limited subset of NSM
>procedures: NULL, and SM_NOTIFY. If it receives an SM_NOTIFY message,
>it initiated reclaim for all locks we hold on that server (if any)
>and ditch all locks this client holds on our box (if any).
>
>(As a special bonus, the new code actually initializes nsm_local_state
>from /var/lib/nfs/state, which we previously didn't).
>  
>
Currently when statd can not open the state file (in change_state()),  
it dies
which in turn causes lock requests to fail because that can't be monitored.
In your kernel implementation, this failure seems to be ignored.  Since
the failure would probably do to the sm directory not existing,  which
also means state file will not able to be created,  it might make sense
to fail the loading of lockd when this happens.

Also I notice that the new nsm_monitor() will only fail with ENOMEM,
regardless if it was able to save state... If it can not save state, 
shouldn't it fail?

SteveD.




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs