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 majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Reply via email to