Date: Tue, 4 Jul 2006 16:40:27 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Michael Collette <Michael.Collette@TestEquity.com> Cc: freebsd-stable@freebsd.org, User Freebsd <freebsd@hub.org> Subject: Re: NFS Locking Issue Message-ID: <20060704134027.GK37822@deviant.kiev.zoral.com.ua> In-Reply-To: <44A99CC1.7070501@TestEquity.com> References: <20060629230309.GA12773@lpthe.jussieu.fr> <20060630041733.GA4941@zibbi.meraka.csir.co.za> <cone.1151802806.162227.42680.1000@zoraida.natserv.net> <20060702162942.D1103@ganymede.hub.org> <44A99CC1.7070501@TestEquity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--2fjX3cMESU3XgGmZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 03, 2006 at 03:40:01PM -0700, Michael Collette wrote: > User Freebsd wrote: > >On Sat, 1 Jul 2006, Francisco Reyes wrote: > > > >>John Hay writes: > >> > >>>I only started to see the lockd problems when upgrading the server side > >>>to FreeBSD 6.x and later. I had various FreeBSD clients, between 4.x > >>>and 7-current and the lockd problem only showed up when upgrading the > >>>server from 5.x to 6.x. > >> > >>It confirms the same we are experiencing.. constant freezing/locking=20 > >>issues. > >>I guess no more 6.X for us.. for the foreseable future.. > > > >Since there are several of us experiencing what looks to be the same=20 > >sort of deadlock issue, I beseech you not to give up >=20 > Honestly trying not to. To tell ya the truth, I've been giving a real=20 > hard look at Ubuntu for my serving needs. This NFS thing has got me=20 > seriously questioning FreeBSD right at the moment. >=20 > >... right now, all=20 > >we've been able to get to the developers is virtually useless=20 > >information (vmstat and such shows the problem, but it doesn't allow=20 > >developers to identify the problem) ... > > > >Is this a problem that you can easily recreate, even on a non-production= =20 > >machine? >=20 > Oh yeah. I've got a couple of ways I'm able to get this to fail. >=20 > Method #1: > --------------------------------------------------------------------- > Let's start with the simplest. The scenario here involves 2 machines,=20 > mach01 and mach02. Both are running 6-STABLE, and both are running=20 > rpcbind, rpc.statd, and rpc.lockd. mach01 has exported /documents and=20 > mach02 is mounting that export under /mnt. Simple enough? >=20 > The /documents directory has multiple subdirectories and files of=20 > various sizes. The actual amount of data doesn't really matter to=20 > produce a failure. All you need to do at this point is to try to copy=20 > files from that mount point to somewhere else on the hard drive. >=20 > cp -Rp /mnt/* /tmp/documents/ >=20 > You may, or not, see that a couple of subdirectories were created, but=20 > no files actually moved over. The cp command is now locked up, and no=20 > traffic moves. This usually takes a second or two to show up as a=20 > problem. I can repeat this with multiple 6-STABLE boxes. >=20 > Turn off rpc.lockd on either the server or client before the cp command,= =20 > and things work. Either way you specified is too vague to reproduce the problem. As was said, you shall supply tcpdump of the failed nfs session. Personally, I tried to do what you described as method 1, and got no hangs, everything copied as it should be. I did it between amd64 6.1-STABLE as of yesterday (client) and same STABLE i386 as server. Monitoring lockd interaction by ethereal also did not reveal anythi= ng. So, what you need to provide to help debug the issue: 1. as detailed information on problem machines configuration as possible 2. exact version of the software you using 3. tcpdump of nfs sessions (for me, it is preferable to get raw tcpdump that could be load into ethereal) 4. log of rpc.lockd both on client and server (see the -d option in man page). Issue seems to be highly specific for some configuration details. And, for instance, me is unable to reproduce it on debug testbench. Without help of the user experiencing trouble, it could take forever to kill that bug. --2fjX3cMESU3XgGmZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEqm/KC3+MBN1Mb4gRApT5AJ0dZjLDl1ljo2wV82EPCioVZcSiyACgx6Ye cLKq2cY3h6obxoG24SBfhE8= =1oCt -----END PGP SIGNATURE----- --2fjX3cMESU3XgGmZ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060704134027.GK37822>