Flush delayed-write data out prior to issuing a rename rpc. This appears

    to fix the problem w/ NFSV3 whereby a make installworld would get into
    high-network-bandwidth situations continuously trying to retry nfs writes
    that fail with a 'stale file handle' error.

1 files changed, 14 insertions, 1 deletions

diff --git a/sys/nfs/nfs_vnops.c b/sys/nfs/nfs_vnops.c
index 0e1554f..7620bcc 100644
--- a/sys/nfs/nfs_vnops.c
+++ b/sys/nfs/nfs_vnops.c
@@ -34,7 +34,7 @@
  * SUCH DAMAGE.
  *
  *	@(#)nfs_vnops.c	8.16 (Berkeley) 5/27/95
- * $Id: nfs_vnops.c,v 1.118 1999/01/27 22:45:13 dillon Exp $
+ * $Id: nfs_vnops.c,v 1.119 1999/01/27 22:45:49 dillon Exp $
  */
 
 
@@ -1567,6 +1567,19 @@ nfs_rename(ap)
 	}
 
 	/*
+	 * 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.