Date: Thu, 3 Jul 1997 09:26:25 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: lederer@bonn-online.com (Sebastian Lederer) Cc: terry@lambert.org, hackers@freebsd.org Subject: Re: NFS locking, was: Re: NFS V3 is it stable? Message-ID: <199707031326.JAA18306@skynet.ctr.columbia.edu> In-Reply-To: <33BB7B0C.41C67EA6@bonn-online.com> from "Sebastian Lederer" at Jul 3, 97 12:12:28 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Sebastian Lederer had to walk into mine and say: > > Terry Lambert wrote: > > > > How do you think NFS server to NFS client responses operate? The > > NFS client has to do the same types of things. > > No,it does not. That's exactly the point. > > The nfs client does a rpc call (e.g. NFSPROC_READ) to the nfs rpc > service on the nfs server, and gets an ordinary rpc reply as a result. > > 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. > That is, for the moment the nfs client becomes a server for the > nlockmgr service, and the rpc.lockd becomes the rpc client. NIS+ callbacks work somewhat like this too (except that you have to keep processing callbacks while waiting for other requests in the server; this requires either fork()ing, threading, or very clever programming. > So there MUST be a rpc.lockd running on the nfs client > to gather these result messages. And this cannot be done in the kernel > because the nlockmgr service must provide the service for > both sides of the locking protocol simultaneously. 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.) 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. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" =============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707031326.JAA18306>