From owner-freebsd-stable@FreeBSD.ORG Wed Jul 5 11:38:48 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74CE916A4DF; Wed, 5 Jul 2006 11:38:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (ll-227.216.82.212.sovam.net.ua [212.82.216.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CF8543D55; Wed, 5 Jul 2006 11:38:46 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k65BcOYw017483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Jul 2006 14:38:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6) with ESMTP id k65BcOFe049139; Wed, 5 Jul 2006 14:38:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6/Submit) id k65BcMJJ049138; Wed, 5 Jul 2006 14:38:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 5 Jul 2006 14:38:22 +0300 From: Kostik Belousov To: Robert Watson Message-ID: <20060705113822.GM37822@deviant.kiev.zoral.com.ua> References: <20060705100403.Y80381@fledge.watson.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yaPAUYI/0vT2YKpA" Content-Disposition: inline In-Reply-To: <20060705100403.Y80381@fledge.watson.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=0.4 required=5.0 tests=ALL_TRUSTED, DNS_FROM_RFC_ABUSE,SPF_NEUTRAL autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on fw.zoral.com.ua Cc: freebsd-stable@freebsd.org, Michel Talon Subject: Re: NFS Locking Issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2006 11:38:48 -0000 --yaPAUYI/0vT2YKpA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 05, 2006 at 10:09:24AM +0100, Robert Watson wrote: > The most significant problem working with rpc.lockd is creating easy to= =20 > reproduce test cases. Not least because they can potentially involve=20 > multiple clients. If you can help to produce simple test cases to=20 > reproduce the bugs you're seeing, that would be invaluable. >=20 =2E....... >=20 > Reducing complex failure modes to easily reproduced test cases is tricky= =20 > also, though. It requires careful analysis, often with ktrace and=20 > tcpdump/ethereal to work out what's going on, and not a little luck to=20 > perform the reduction of a large trace down to a simple test scenario. T= he=20 > first step is to try and figure out what, if any, specific workload resul= ts=20 > in a problem. For example, can you trigger it using work on just one=20 > client against a server, without client<->client interactions? This make= s=20 > tracking and reproduction a lot easier, as multi-client test cases are=20 > really tricky! Once you've established whether it can be reproduced with= a=20 > single client, you have to track down the behavior that triggers it --=20 > normally, this is done by attempting to narrow down the specific program = or=20 > sequence of events that causes the bug to trigger, removing things one at= a=20 > time to see what causes the problem to disappear. This is made more=20 > difficult as lock managers are sensitive to timing, so removing a high lo= ad=20 > item from the list, even if it isn't the source of the problem, might cau= se=20 > it to trigger less frequently. I made the patch for rpc.lockd that could somewhat ease obtaining debug information. Patch is available at http://people.freebsd.org/~kib/rpc.lockd-debug.patch No functional changes. Patch only adds dumping of currently held locks (as perceived by lockd) on receiving of SIGUSR1. You need to specify debug level 2 or 3 to obtain the dump. Also, the both lockd processes now put identification information in the proctitle (srv and kern). SIGUSR1 shall be sent to srv process. --yaPAUYI/0vT2YKpA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEq6SuC3+MBN1Mb4gRApCoAKCtMr8xxjm6SRZo/v19JLCc6AYa/ACffhrk DwT7qAM1B0b73pWvr4m7GxU= =4Dzc -----END PGP SIGNATURE----- --yaPAUYI/0vT2YKpA--