From owner-freebsd-current Fri Feb 5 18:14:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA10830 for freebsd-current-outgoing; Fri, 5 Feb 1999 18:14:05 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA10825 for ; Fri, 5 Feb 1999 18:14:04 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id SAA01635; Fri, 5 Feb 1999 18:03:46 -0800 (PST) (envelope-from dillon) Date: Fri, 5 Feb 1999 18:03:46 -0800 (PST) From: Matthew Dillon Message-Id: <199902060203.SAA01635@apollo.backplane.com> To: "D. Rock" , N Cc: current@FreeBSD.ORG Subject: Re: Seeing NFS saturation 'loop' when installworld'ing to NFS / and /usr References: <199902060101.CAA04062@vodix.aremorika> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, I think I found the problem. I believe what is going on is that dirty buffers are being held across an nfs_rename() call under NFS V3. Under NFS V2, most such buffers are written synchronously. Under NFS V3, however, it appears to work differently. One of the following two sequences is causing the problem: * write A * rename A B * delete B or * write B * rename A B * delete B I can't tell which. The dirty buffers stay in the buffer cache until after the rename, and then flushdirtybuffers() comes along and tries to flush them. The buffers being flushed get an NFS 'Stale file Handle' error. Not only that, but due to the error the buffer remains dirty and gets flushed out again by flushdirtybuffers(). This occurs add-nausium until some other event comes along and clears enough buffers such that flushdirtybuffers() will exit its loop. This could also be responsible or partially responsible for the NFS-based dirty-buffers panic on shutdown. -- I would appreciate it if people experiencing either problem try this patch. It is rather important that we test this patch big-time because we will want to get it into -3.1 if it turns out to fix some of the problems. Even if this fixes some things, we still have a potential stale-file looping condition in flushdirtybufs() that must be addressed. If the stale file handle error is a fatal error under NFS, we should generate a system log message and eradicate the buffer(s) in question rather then leave them sitting around in the buffer cache. -Matt Matthew Dillon Index: nfs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/nfs/nfs_vnops.c,v retrieving revision 1.119 diff -u -r1.119 nfs_vnops.c --- nfs_vnops.c 1999/01/27 22:45:49 1.119 +++ nfs_vnops.c 1999/02/06 01:56:23 @@ -1567,6 +1567,19 @@ } /* + * We have to flush B_DELWRI data prior to renaming + * the file. If we don't, the delayed-write buffers + * can be flushed out later after the file has gone stale + * under NFSV3. NFSV2 does not have this problem because + * ( as far as I can tell ) it flushes dirty buffers more + * often. + */ + + VOP_FSYNC(fvp, fcnp->cn_cred, MNT_WAIT, fcnp->cn_proc); + if (tvp) + VOP_FSYNC(tvp, tcnp->cn_cred, MNT_WAIT, tcnp->cn_proc); + + /* * If the tvp exists and is in use, sillyrename it before doing the * rename of the new file over it. * XXX Can't sillyrename a directory. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message