From owner-freebsd-current Thu Feb 11 01:24:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA18110 for freebsd-current-outgoing; Thu, 11 Feb 1999 01:24:16 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from uni-sb.de (uni-sb.de [134.96.252.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA18101 for ; Thu, 11 Feb 1999 01:24:10 -0800 (PST) (envelope-from rock@cs.uni-sb.de) Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.252.31]) by uni-sb.de (8.9.3/1999020800) with ESMTP id KAA10575; Thu, 11 Feb 1999 10:24:05 +0100 (CET) Received: from cs.uni-sb.de (maxtnt-010.rz.uni-sb.de [134.96.70.137]) by cs.uni-sb.de (8.9.3/1999020800) with ESMTP id KAA23485; Thu, 11 Feb 1999 10:24:02 +0100 (CET) X-Authentication-Warning: mail.cs.uni-sb.de: Host maxtnt-010.rz.uni-sb.de [134.96.70.137] claimed to be cs.uni-sb.de Message-ID: <36C2A1E3.4404804@cs.uni-sb.de> Date: Thu, 11 Feb 1999 10:24:51 +0100 From: "D. Rock" X-Mailer: Mozilla 4.5 [de] (WinNT; U) X-Accept-Language: de MIME-Version: 1.0 To: Matthew Dillon CC: "D. Rock" , N , current@FreeBSD.ORG Subject: Re: Seeing NFS saturation 'loop' when installworld'ing to NFS / and /usr References: <199902060101.CAA04062@vodix.aremorika> <199902060203.SAA01635@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This doesn't fix my problem (my isn't even rename or delete related) As I writed some time before, I always get the wrong results if I generate the termcap.db in an NFSv3 mounted directory. It doesn't matter which machine is the NFS server (tried Solaris 7 and the NFS client machine itself). The generated file has *always* the wrong size (always the same: 1077760 Bytes, instead of 1245184 Bytes, which it should have). With NFSv2 the output is OK. Can anyone please test this if they have the same problem. It is quite easy: mkdir /NFS/termcap; cp /usr/src/share/termcap/* /NFS/termcap cd /NFS/termcap; make redo this with NFSv2 and v3 and compare the results. If someone else has the same problem it would be nice if he can drop me a note, so I know I'm not alone... Anyone with /usr/obj NFS mounted should have the same problems. I don't even dare to do a make release on an NFSv3 mounted chroot directory. Even if the make succeeded I wouldn't trust the results. NFSv2 seems quite stable now. Daniel Matthew Dillon schrieb: > 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