Date: Fri, 5 Feb 1999 18:03:46 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "D. Rock" <rock@wurzelausix.CS.Uni-SB.DE>, N <niels@bakker.net> Cc: current@FreeBSD.ORG Subject: Re: Seeing NFS saturation 'loop' when installworld'ing to NFS / and /usr Message-ID: <199902060203.SAA01635@apollo.backplane.com> References: <199902060101.CAA04062@vodix.aremorika>
next in thread | previous in thread | raw e-mail | index | archive | help
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
<dillon@backplane.com>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902060203.SAA01635>