Date: Fri, 04 Jul 1997 09:17:07 +0200 From: Sebastian Lederer <lederer@bonn-online.com> To: Bill Paul <wpaul@skynet.ctr.columbia.edu> Cc: hackers@FreeBSD.ORG Subject: Re: NFS locking, was: Re: NFS V3 is it stable? Message-ID: <33BCA373.41C67EA6@bonn-online.com> References: <199707031326.JAA18306@skynet.ctr.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Bill Paul wrote: > > > > The locking client does a rpc call to the nlockmgr rpc service on the > > nfs server (e.g. NLM_LOCK_MSG). No rpc reply is sent back. > > The result of the locking operation is then sent as an entirely > > different > > rpc call from the nfs server to the nlockmgr service on the nfs client > > (NLM_LOCK_RES). > > This is not that hard to do: in the server side stubs, you just return > NULL to the dispatcher. This prevents it from automatically calling > svc_sendreply(). The client can do this by setting the RPC call timeout > to 0; in this case it always gets back an RPC_TIMEDOUT error, but the > call returns immediately. You're right, this not a problem, in fact it's already implemented in Andrew Gordon's rpc.lockd (which does no actual locking, only the nlockmgr rpc protocol). > Mmmnnn... I have to differ with you here. With SGI IRIX 6.2, the NFS > lock manager is in fact implemented inside the kernel. There is a > /usr/etc/rpc.lockd, but it's just a small program that launches the > lock manager as a kernel-space process. Actually, it may really be a > kernel-space thread: no lock manager process shows up when you do a > 'ps -ef' however the 'nlockmgr' service is registered with the portmapper. > (It's registered on port 2049 too, which is significant because that's > where nfs is registered too.) There is no llockmgr service registered > anymore since it's no longer required (the kernel can calk to the > lock manager process/thread directly instead of needing to use RPCs.) Right, one could also implement the lockd as a kernel process, just like the nfs server. But even then there would be still an nlockmgr rpc service running on the nfs client, as you have pointed out. The nlockmgr protocol cannot be handled just by the client code. It's interesting that the nlockmgr port is the same as the nfs port, that would probably mean that the lock manager has been combined with the in-kernel nfs service (maybe that's what nfssys(LM_SVC) is for, but at least on Sun, nfssys is undocumented, so I'm only guessing) It's also interesting that you mention a llockmgr protocol. Does that mean there *was* a (user process) rpc.lockd on the nfs client in earlier versions of IRIX, and that the llockmgr protocol was used by the kernel to communicate with it? > I'm not certain if I like this approach or not; on the one hand, it > makes the llockmgr protocol unnecessary, but on the other hand, if the > lock manager kernel process/thread goes insane (as the NFS lock manager > is wont to do, in my experience), there's no way to kill/restart it. Assuming that an in-kernel lockd implementation is much more difficult than a user-process implementation, I would suggest that we should try a user-process based implementation first. If that works, maybe later we could move to a kernel process for performance optimization. But I think for now it's more important to have something working than to have improved performance. The overall performance of nfs locking is not / won't be great anyway. What do you think? Best regards, Sebastian Lederer -- Sebastian Lederer lederer@bonn-online.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?33BCA373.41C67EA6>