Re: in-kernel rpc.statd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sunday September 3, [email protected] wrote:
> In article <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux