Chuck Lever 写道: > > 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. > That's why I don't find the codes! Thanks! The statd code does have some rough, but, we can modify it when we need. Do you have implemented those codes? If have, please give me a copy, or a git commit. thanks, Mi Jinlong -- 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
