From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 14:54:27 2004 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 3C6E316A4D9; Tue, 12 Oct 2004 14:54:27 +0000 (GMT) Received: from maxlor.mine.nu (c-213-160-32-54.customer.ggaweb.ch [213.160.32.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFF6A43D46; Tue, 12 Oct 2004 14:54:26 +0000 (GMT) (envelope-from benlutz@datacomm.ch) Received: from localhost (localhost [127.0.0.1]) by maxlor.mine.nu (Postfix) with ESMTP id BC05E2F1; Tue, 12 Oct 2004 16:54:25 +0200 (CEST) Received: from maxlor.mine.nu ([127.0.0.1]) by localhost (midgard [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92097-05; Tue, 12 Oct 2004 16:54:24 +0200 (CEST) Received: from merlin.intranet (merlin.intranet [10.0.0.16]) by maxlor.mine.nu (Postfix) with ESMTP id 030DACC; Tue, 12 Oct 2004 16:54:23 +0200 (CEST) From: Benjamin Lutz To: freebsd-current@freebsd.org Date: Tue, 12 Oct 2004 16:54:18 +0200 User-Agent: KMail/1.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1227177.FBU61uCNiF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200410121654.23482.benlutz@datacomm.ch> X-Virus-Scanned: by amavisd-new at maxlor.mine.nu cc: Robert Watson Subject: Re: NFS trouble 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, 12 Oct 2004 14:54:27 -0000 --nextPart1227177.FBU61uCNiF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > > > Are other NFS clients able to continue to access the NFS > > > server without problems? > > > > Partially. Other clients can access parts of the exported share. It > > appears that as soon as they access the directory in which the first > > program froze, they freeze as well. > > If you log into the server and try to access that directory, do you > succeed? Yes, no problems or slowdowns. > You talked about having non-FreeBSD 5.x clients as well, I think, in an > earlier e-mail -- if a FreeBSD 5.x client wedges on a directory on the > server, will another non-FreeBSD client also wedge on touching the > directory? I'm sorry, I misread the question. What I was trying to say is that other=20 programs on the same machine that has one program in a freeze can still=20 access the NFS share, until they access the same directory that the=20 frozen program is accessing. Other clients (as in other machines) are totally unaffected. > Is it always the same director(y/ies) in which the wedge occurs? Yes, given that I use more or less the same directory to store the files=20 in that I currently work with. It is more than one directory though, I've=20 seen this with at least 4 different ones. > The behavior you describe above sounds like it might be a problem with > the server, or, that the server generates bad or maybe just different > responses that trigger a client bug for particular directories or in > particular circumstances? With the exceptions of things like > distributed advisory locking (rpc.lockd, etc), bugs in one client won't > generally trigger the problem in another client a the same time unless > it's a common property of the directory they touch. Given that the problem occurs with both a Gentoo machine acting as NFS=20 server and a FreeBSD 4.10 machine acting as NFS server (the latter has=20 been working fine since 4.10 was released, and under previous releases=20 before that), I think those work just fine. > Ruling out debug.mpsafenet and/or if_re checksum issues would both be > useful things to do. I strongly suspect it was the re checksum issue. I've disabled both=20 debug.mpsafenet and txcsum offloading, and NFS seems to work fine again.=20 I've copied a few GB of data back and forth, no freezes. Thanks again for your time. Benjamin --nextPart1227177.FBU61uCNiF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBa/AfgShs4qbRdeQRAosEAJ9JQ3INUa2qgcfUtjoO3nq5W9zr/gCgkh52 hgCCcO3GtdPT9kwqsoRFfYQ= =atXQ -----END PGP SIGNATURE----- --nextPart1227177.FBU61uCNiF--