From owner-freebsd-current@FreeBSD.ORG Tue May 13 14:29:10 2003 Return-Path: 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 26E0237B401; Tue, 13 May 2003 14:29:10 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AB5043F3F; Tue, 13 May 2003 14:29:09 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h4DLSxOn021526; Tue, 13 May 2003 17:28:59 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)h4DLSxcv021523; Tue, 13 May 2003 17:28:59 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 13 May 2003 17:28:59 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Don Lewis In-Reply-To: <200305132111.h4DLBaM7051295@gw.catspoiler.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: bsder@allcaps.org cc: alfred@FreeBSD.org cc: current@FreeBSD.org Subject: Re: rpc.lockd spinning; much breakage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2003 21:29:10 -0000 On Tue, 13 May 2003, Don Lewis wrote: > > I should clarify this statement: I no longer get the odd hangs when it > > comes to client and server interactions when contending a lock established > > on the server and now tested by the client. I still bump into the "client > > isn't woken up in a timely manner after a lock is released by the same or > > another client". Here's the demonstration case with a bit more detail > > from what I presented earlier. The server runs on host cboss, the client > > runs twice on host crash1 on different pty's. In this scenario, each > > client attempts to grab an exclusive lock, potentially blocking, and then > > sleep for 10 seconds (this is with one of the earlier posted patches): > > Try adding the lock_answer() calls I suggested in an earlier message ... I did do this, but on reflection, if I'm using NFSv2 (which I am for the root file system), it sounds like changes to the nlm4 code won't help. I put a similar instance of lock_answer() into nlm_granted_1_svc(), and that seems to have greatly improved the latency for this case. I'll test NFSv3 when I get home this evening. So that change sounds like a winner for that issue. This leaves the problem of getting EACCES back for locks contended by an NFS client against consumers directly on the server, rather than the client retrying. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories