From owner-freebsd-stable@FreeBSD.ORG Wed Jul 5 13:20:17 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 B31EB16A4DE; Wed, 5 Jul 2006 13:20:17 +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 F2C1543D46; Wed, 5 Jul 2006 13:20:16 +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 k65DK6WL020704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Jul 2006 16:20:06 +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 k65DK5of060910; Wed, 5 Jul 2006 16:20:05 +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 k65DK59Z060909; Wed, 5 Jul 2006 16:20:05 +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 16:20:05 +0300 From: Kostik Belousov To: Robert Watson Message-ID: <20060705132005.GP37822@deviant.kiev.zoral.com.ua> References: <20060705100403.Y80381@fledge.watson.org> <20060705113822.GM37822@deviant.kiev.zoral.com.ua> <20060705122040.GN37822@deviant.kiev.zoral.com.ua> <20060705140225.X18236@fledge.watson.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="B3NBd8mrXZtPJEYR" Content-Disposition: inline In-Reply-To: <20060705140225.X18236@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 13:20:17 -0000 --B3NBd8mrXZtPJEYR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 05, 2006 at 02:04:59PM +0100, Robert Watson wrote: >=20 > On Wed, 5 Jul 2006, Kostik Belousov wrote: >=20 > >>Also, the both lockd processes now put identification information in th= e=20 > >>proctitle (srv and kern). SIGUSR1 shall be sent to srv process. > > > >Hmm, after looking at the dump there and some code reading, I have noted= =20 > >the following: > > > >1. NLM lock request contains the field caller_name. It is filled by (let= =20 > >call it) kernel rpc.lockd by the results of hostname(3). > > > >2. This caller_name is used by server rpc.lockd to send request for host= =20 > >monitoring to rpc.statd (see send_granted). Request is made by clnt_call= ,=20 > >that is blocking rpc call. > > > >3. rpc.statd does getaddrinfo on caller_name to determine address of the= =20 > >host to monitor. > > > >If the getaddrinfo in step 3 waits for resolver, then your client machin= e=20 > >will get locking process in"lockd" state. > > > >Could people experiencing rpc.lockd mistery at least report whether=20 > >_server_ machine successfully resolve hostname of clients as reported by= =20 > >hostname? And, if yes, to what family of IP protocols ? >=20 > It's not impossible. It would be interesting to see if ps axl reports th= at=20 > rpc.lockd is in the kqread state, which would suggest it was blocked in t= he=20 ^^^^^^^^^^^^ rpc.statd :). > resolver. We probably ought to review rpc.statd and make sure it's=20 > generally sensible. I've noticed that its notification process on start = is=20 > a bit poorly structured in terms of how it notifies hosts of its state=20 > change -- if one host is down, it may take a very long time to notify oth= er=20 > hosts. --B3NBd8mrXZtPJEYR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEq7yEC3+MBN1Mb4gRAl6hAJkBxQS3CgwTXHTUpUYSK/z7SedtrwCfXksU qepdFQmKwhGll47wICxaJDg= =anyo -----END PGP SIGNATURE----- --B3NBd8mrXZtPJEYR--