Date: Tue, 18 Jun 1996 18:59:22 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: karl@mcs.com (Karl Denninger, MCSNet) Cc: randy@zyzzyva.com, dennis@etinc.com, hackers@FreeBSD.org Subject: Re: BSDI 2.0 vs. FreeBSD 2.x Message-ID: <199606190159.SAA11786@phaeton.artisoft.com> In-Reply-To: <m0uW2BZ-000IDOC@venus.mcs.com> from "Karl Denninger, MCSNet" at Jun 18, 96 09:55:17 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Karl, knowing you from the days of ISC I'm surprised you would > > give BSDI that much slack. I hardly think that an OS lacking > > a 'lockd' qualifies as an NFS server. Try juggling a network > > of BSDI NFS realestate in a network of machines that can > > actually do file locking... not fun. > > NOBODY does NFS file locking properly. NOBODY. > > Trust me on this -- 10+ years of experience with this beast has convinced me > that absolutely no one has implemented NFS locking in a manner that I would > trust for anything mission critical. So I don't. It was quite tempting to implement NFS file locking using an alternate protocol; however, interoperability with Sun was a major concern, so I let someone else do the protocol, and piped up with my server lockd support kernel changes when the lockd stub was released. In practice, it's possible to resolve much of the NFS file locking issues by first asserting locks locally, then over the wire. This is the much-touted "VOP_ADVLOCK" layering fix I always go on about. There is a potential for races from a signel client without this fix. There is a potential for races between multiple clients in the "most correct" implementation, which I believe to be SunOS 4.1.3_U1. These races are timeout timer related, and can be easily resolved by syncing clients to the server time based with a "follow time" of one second or more. We used this successfully for NFS-based CVS access for a number of years, without many problems. Can you reliably recover from server failures? It depends. If your statd tiemout is less than your server reboot period before it comes back on line, yes. The remaining NFS issues are related to distributed cache coherency, and are resolvable with two stage commit protocols for file access, where the locking is used to ensure implied metastate between several files. This assumes that server writes are not asynchronus, nor are they clusters outside of a single cylinder without a hardware write commit assist of some kind (Sun has some hardware to provide a battery backed write cache that can be commited on system restart). In general, if you have a SunOS 4.1.3_U1 NFS locking implementation, and you implement proper ordering protocols (sendmail and mail readers do *not*), then you *can* "trust" the locking. This requires particiaption in the ordering protocols by the app writers. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606190159.SAA11786>