Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Oct 2004 16:54:18 +0200
From:      Benjamin Lutz <benlutz@datacomm.ch>
To:        freebsd-current@freebsd.org
Cc:        Robert Watson <rwatson@freebsd.org>
Subject:   Re: NFS trouble
Message-ID:  <200410121654.23482.benlutz@datacomm.ch>
In-Reply-To: <Pine.NEB.3.96L.1041012043847.55701F-100000@fledge.watson.org>
References:  <Pine.NEB.3.96L.1041012043847.55701F-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
--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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410121654.23482.benlutz>