From owner-freebsd-current  Wed May 22 23:10:52 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id XAA21557
          for current-outgoing; Wed, 22 May 1996 23:10:52 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA21545
          for <current@freebsd.org>; Wed, 22 May 1996 23:10:48 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id QAA01537; Thu, 23 May 1996 16:05:12 +1000
Date: Thu, 23 May 1996 16:05:12 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199605230605.QAA01537@godzilla.zeta.org.au>
To: gallatin@stat.Duke.EDU, jkh@time.cdrom.com
Subject: Re: NFS v3 problem
Cc: current@freebsd.org
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > > I think that I've tracked this down to ar interacting with nfsv3; it
> > > doesn't seem to matter if the f77 or ranlib steps are run when the fs
> > > is mounted nfsv2 or nfsv3.  Ranlib will always fail if ar was run on
> > > an nfsv3 mounted fs, and always succeed if ar was run on an nfsv2
> > > mounted fs. 

This problem is very old.  I don't think nfsv3 has ever been usable in
FreeBSD, although I use it every day, mostly read-only.

>After doing a little digging, I see that the v2 and local disk version
>of what ar spits out is 61454 bytes of meaningful data, but the v3
>version is all 0's above 57352 bytes.

>According to ktrace, the last thing ar does before closing the file is
>to ftruncate() it to the size it should be.  an ar with the
>ftruncate() called hacked out of it produces a file 57352 bytes long.
>Apparently ftruncate() is accounting for the 0's.

The problem seems to me much more fundamental.  In the following program,
under -current, the last write() doesn't make it to the disk:

#include <sys/types.h>
#include <string.h>
#include <unistd.h>

int main(void)
{
    char buf[0x2000];

    memset(buf, '1', 1);
    write(1, buf, 1);
    memset(buf, '2', 0x2000);
    write(1, buf, 0x2000);		/* this block size is critical */
    memset(buf, '3', 1);
    write(1, buf, 1);
    return 0;
}

$ mount -t nfs -o -3 localhost:/usr /mnt
$ cd /mnt/somewhere/that/probably/doesnt/matter
$ /tmp/aboveprog >z
$ cat z			# no 3 at the end

There is also a vm bug in ktrace.  This is independent of the nfs bug:

$ cd /usr/src/lib/libtermcap
$ make
$ rm obj/libtermcap.a
$ ktrace -id make
$ cp ktrace.out z
$ kdump >/dev/null	# fails
$ kdump -f z >/dev/null	# works
$ cmp ktrace.out z	# fails

Bruce