in-kernel rpc.statd

in-kernel rpc.statd

[Christian Guggenberger]

Hi,

I'd like to ask if someone is maintaining a patchset, that implements
the in-kernel rpc.statd (as found in SuSE kernels). I tried to fiddle
some patches of Suse-10.1 into 2.6.17, but failed, unfortunately.

thanks for your help,

 - Christian
 

-- 
VGER BF report: U 0.51084

Re: in-kernel rpc.statd

[Jan Engelhardt]

>I'd like to ask if someone is maintaining a patchset, that implements
>the in-kernel rpc.statd (as found in SuSE kernels). I tried to fiddle
>some patches of Suse-10.1 into 2.6.17, but failed, unfortunately.

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?


Jan Engelhardt
-- 

-- 
VGER BF report: H 7.21645e-16

Re: in-kernel rpc.statd

[Trond Myklebust]

On Sun, 2006-09-03 at 23:01 +0200, Jan Engelhardt wrote:
> >I'd like to ask if someone is maintaining a patchset, that implements
> >the in-kernel rpc.statd (as found in SuSE kernels). I tried to fiddle
> >some patches of Suse-10.1 into 2.6.17, but failed, unfortunately.
> 
> 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?

Yes. Locking over NFSv2/v3 won't work without it.

That said, there is no reason why we need an rpc.statd in the kernel
when the nfs-utils package already provides one that works fine in
userland.

Cheers,
  Trond


-- 
VGER BF report: H 2.2074e-05

Re: in-kernel rpc.statd

[Christian Guggenberger]

> > 
> > 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?
> 
> Yes. Locking over NFSv2/v3 won't work without it.
> 
> That said, there is no reason why we need an rpc.statd in the kernel
> when the nfs-utils package already provides one that works fine in
> userland.
>

I know. The reason behind my query was just that Suse distros - SLES9 at
least - do not provide userland rpc.statd anymore.

cheers.
 - Christian

-- 
VGER BF report: H 3.23172e-09

Re: in-kernel rpc.statd

[Bernd Eckenfels]

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.

Gruss
Bernd

-- 
VGER BF report: H 0.429236

Re: in-kernel rpc.statd

[Neil Brown]

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