From owner-freebsd-hackers Tue May 4 13: 0:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 8E2E115740 for ; Tue, 4 May 1999 13:00:08 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id UAA53777; Tue, 4 May 1999 20:29:38 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Tue, 4 May 1999 20:29:38 +0100 (BST) From: Doug Rabson To: Kevin Day Cc: Matthew Dillon , jso@research.att.com, hackers@freebsd.org Subject: Re: kern/11470: V3 NFS problem (fwd) In-Reply-To: <199905041906.OAA07822@home.dragondata.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 4 May 1999, Kevin Day wrote: > > :From: Kevin Day > > : > > :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