Date: Thu, 19 Dec 1996 15:30:02 -0500 (EST) From: "Ron G. Minnich" <rminnich@Sarnoff.COM> To: Terry Lambert <terry@lambert.org> Cc: freebsd-hackers@freebsd.org Subject: rpc.lockd in nfs in freebsd vs. sun nfs locking Message-ID: <Pine.SUN.3.91.961219151510.18130D-100000@terra> In-Reply-To: <199612191820.LAA11849@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry points out that: > 1) The rpc.lockd and rpc.statd currently in the source tree > correctly interoperate with Sun's locking implementation. No argument. I'm not sure this really helps that much, because just interoperating with sun's implementation does not really mean you have useful locking, which is what the original question really concerned. > 2) The Sun locking works correctly if you obey order of operation > protocols in your client code. If it doesn't work for someone, > it's pilot error, not an unclosable hole in the code. Hmm, there still seem to be problems as late as solaris 2.5. All I can say is friends of mine are still trying to use the locking stuff and still having problems, and I can't see any obvious things wrong in what they're doing. As late as Solaris 2.4, we were still seeing an occasional 'lock storm', where RPC lock traffic would eat the wire on one particular error condition that would occur when a client rebooted. This was elicited by sendmail locking in /var/spool/mail. We just had a lockup the other day on a 2.5 machine, we're not sure why but the process that was hung was ... sendmail. The guy who rebooted the machine didn't get me a core dump though. > 3) The FreeBSD implementation of rpc.lockd (for the NFS server) > always returns "success" to the NFS client instead of making > local fcntl() calls to assert the locks on the local system on > the clients behalf. Yes, BUT: is it locking or not? If so, that's great. If not, then it's hard to see how this helps an application writer -- and that's the real end goal. > 4) Patches to do this were submitted, but never integrated. They > remain available in the -current list archive for anyone who > is interested in integrating them. So: locking does not work. Anyway seems you know what to do in order to fix it, but it's still not really there, right? It would be nice to see this go in -- people keep asking for it. > 6) NFS locking is not stateless. Not what I said. What I said is, given that NFS is stateless (which you can argue over the merits of), locking gets to be messy, since you have to glue on an inherently stateful set of operations (locking) over a stateless base. Having modified NFS servers to be stateful, and having then used that state to support application-level locking via locks in mmap()-ed files, I can tell you locking is a bit easier with a stateful server. And yes, I know that locks in files are different than locks on files. But I think the experiences are applicable. Anyways, thanks for the note. It sounds like freebsd is close but not quite there ... maybe the changes will make it in next time. ron
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.961219151510.18130D-100000>