Date: Tue, 4 May 1999 20:29:38 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Kevin Day <toasty@home.dragondata.com> Cc: Matthew Dillon <dillon@apollo.backplane.com>, jso@research.att.com, hackers@freebsd.org Subject: Re: kern/11470: V3 NFS problem (fwd) Message-ID: <Pine.BSF.4.05.9905042023430.637-100000@herring.nlsystems.com> In-Reply-To: <199905041906.OAA07822@home.dragondata.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 4 May 1999, Kevin Day wrote: > > :From: Kevin Day <toasty@home.dragondata.com> > > : > > :Ok, I've been playing with your last patches (just before they were > > :committed). > > : > > :1) if I 'sysctl -w vfs.nfs.async=1' on the server, the client will > > :eventually get deadlocked, with most processes stuck in 'nfsrcvlk' or > > :'nfsinval'(i think) > > > > Yes, I'm sure there are still a couple of lockup situations that > > we need to fix in this area. I need to know whether this is via > > NFSV2 or NFSV3 and whether this is a UDP or TCP mount. And, if it is > > a TCP mount, whether the problem occurs with a UDP mount. A similar > > situation occured with TCP when I was doing makes that turned out to be > > a data corruption bug related to multiple RPC's winding up in the same > > mbuf. > > > > Note: If your *SERVER* is not running the latest -current, you have to > > upgrade it. If your server is running FreeBSD-stable, the TCP fix (which > > is a server-side bug) has NOT yet been committed to FreeBSD-stable. > > We're mounting with NFS V3, and UDP. The nfs server in most of my testing was a > 2.2.5 server, but this also occurred with a 4.0 nfs server. I would expect the same behaviour for virtually any version of FreeBSD NFS server since 2.2. I don't think the algorithm in the server has changed since then. Basically, what is happening is that we are using the modtime of a directory to validate the seek offsets which are being sent to us by a client. Since files are being removed, this means that the client is told that its cookies are invalid and ought to re-read the directory from scratch. Instead it is giving up and pretending that the directory was truncated. This is a client bug, not a FreeBSD server bug but it would be possible to use a different algorithm for validating directory seek cookies. It would probably need hooks into the underlying vfs to be really efficient. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9905042023430.637-100000>