On Jan 18, 2010, at 5:51 AM, Mi Jinlong wrote:
Hi Chuck,
Chuck Lever 写道:
On Jan 15, 2010, at 4:35 AM, Mi Jinlong wrote:
...snip...
Maybe, the kernel should fix this.
What did you have in mind?
I think when lockd restart, statd should restart too and sent
sm-notify to other client.
Sending notifications is likely the correct thing to do if lockd is
restarted while there are active locks. A statd restart isn't
necessarily required to send reboot notifications, however. You
can do
it with "sm-notify -f".
The problem with "sm-notify -f" is that it deletes the on-disk
monitor
list while statd is still running. This means the on-disk monitor
list
and statd's in-memory monitor list will be out of sync. I seem to
recall that sm-notify is run by itself by cluster scripts, and that
could be a real problem.
As implemented on RH, "service nfslock restart" will restart statd
and
force an sm-notify anyway, so no real harm done, but that's pretty
heavyweight (and requires that admins do "service nfs stop; service
nfslock restart; service nfs start" or something like that if they
want
to get proper lock recovery).
A simple restart of statd (outside of the nfslock script) probably
won't
be adequate, though. It will respect the sm-notify pidfile, and not
send notifications when started up. I don't see a flag on statd to
force it to send notifications on restart (-N only sends
notifications;
it doesn't also start the statd daemon).
In a perfect world, when lockd restarts, it would send up an
SM_SIMU_CRASH, and statd would do the right thing: if there are
monitored peers, it would send reboot notifications, and adjust it's
monitor list accordingly; if there were no monitored peers, it
would do
nothing. Thus no statd restart would be needed.
Did this part have implemented at kernel?
I don't find the codes about SM_SIMU_CRASH.
There isn't such code in the current kernel. I'm simply suggesting a
possible solution.
I'm coding up a patch that does this so we can experiment with it.
I'm a little worried that the current statd code won't do the right
thing, or even worse, it would crash. That would make it difficult to
introduce such a patch without triggering regressions.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
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
