lkml.org 
[lkml]   [2006]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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/

\
 
 \ /
  Last update: 2006-09-04 00:55    [W:0.039 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site