Date: Tue, 18 Mar 2003 00:47:42 -0800 (PST) From: "Andrew P. Lentvorski, Jr." <bsder@allcaps.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: Steve Sizemore <steve@ls.berkeley.edu>, Dan Nelson <dnelson@allantgroup.com>, Alfred Perlstein <bright@mu.org>, <current@FreeBSD.ORG> Subject: Re: NFS file unlocking problem Message-ID: <Pine.LNX.4.44.0303180018130.18118-100000@mail.allcaps.org> In-Reply-To: <3E768C47.229C1DF0@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 17 Mar 2003, Terry Lambert wrote: > Actually, given this, I don't understand how FreeBSD server side > proxy locking can actually work at all; it would incorrectly > coelesce locks with local locks when the l_pid matched, which > would be *all* locks in the lockd, and then incorrectly release > them when a local process exited, or any process on any remote > system unlocked an overlapping range (possibly in error). Please don't speculate without having reviewed the code. It works because I rewrote rpc.lockd so that it does the required housekeeping itself. The FreeBSD lockd is the only open-source locking daemon that actually passes the Connectathon interoperability tests. When rpc.lockd gets a lock request, it immediately attempts to lock the *entire* underlying file on the NFS server (or fails). It then keeps internal track of the partial lock requests so that they *don't* coalesce (including l_pid from the target system). rpc.lockd only releases the underlying file when all NFS locks go away. Yes, it does create extra contention if someone tries to do partial file locking via both NFS and the local filesystem simultaneously. I deemed this an acceptable compromise in order to cover up for the problems in the FreeBSD locking space since most people who truly need locking generally have dedicated file servers. -a To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.44.0303180018130.18118-100000>