From owner-freebsd-current Tue Mar 18 13:21:19 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D514D37B401 for ; Tue, 18 Mar 2003 13:21:17 -0800 (PST) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E53C43F75 for ; Tue, 18 Mar 2003 13:21:17 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0203.cvx22-bradley.dialup.earthlink.net ([209.179.198.203] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18vOW8-0006A9-00; Tue, 18 Mar 2003 13:21:05 -0800 Message-ID: <3E778D6F.F4599EE6@mindspring.com> Date: Tue, 18 Mar 2003 13:19:43 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Andrew P. Lentvorski, Jr." Cc: Steve Sizemore , Dan Nelson , Alfred Perlstein , current@FreeBSD.ORG Subject: Re: NFS file unlocking problem References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4e275cfecb37ad4a9144acbe8d829e408387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Andrew P. Lentvorski, Jr." wrote: > On Mon, 17 Mar 2003, Terry Lambert wrote: > 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. I already knew this was the answer, actually. > 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. So then the first question that should have been asked is "are there local server clients?". If there are local server clients, then the problem is obviously there. Out of curiosity, why didn't you use my F_RSETLK/F_RGETLK and l_rsysid and delayed coelescing patches for lockmgr, so that you could support host lock coherency? Was the issue F_RSETLKW requiring a blocking context? It's fairly easy to make this async-but-FIFO-ordered. If you want, I can update them (they old ones are currently available on http://www.freebsd.org/~terry ). They do not break binary compatability. I'm even willing to do the F_RSETLKW queue insertion management for the async part... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message