Messages in this thread | | | From | Neil Brown <> | Date | Mon, 4 Sep 2006 08:52:15 +1000 | Subject | Re: in-kernel rpc.statd |
| |
On Sunday September 3, ecki@lina.inka.de wrote: > In article <Pine.LNX.4.61.0609032255010.6844@yvahk01.tjqt.qr> you wrote: > > Hm. I do not have a rpc.statd userspace program nor kernel daemon (running > > on 2.6.17-vanilla). Yet everything is working. Is there a specific need for > > statd? > > It is more or less an uptime notification protocol for NFS locks. I think > NFS clients can recover from a reboot without the help of the statd in most > situations.
No.
If a client has a lock and the server reboots, then the client loses the lock and must recovery it during the grace period (first 45 seconds while the server is running again). Without statd it doesn't know to do this, and it certainly doesn't know when to do it. So there is a chance that the server will give the lock to some other client. Bad.
On the flip side, when a client reboots, the server is left holding the lock and will not drop it until it discovers that the client has rebooted, and this can only be discovered via statd. So without statd you end up with locks that can only be removed by the sysadmin (or a server reboot). In early days when lockd/statd implementations (not necessarily linux) were even more clunky than they are today, stale locks were not particularly uncommon.
NeilBrown
-- VGER BF report: H 0.018873 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |