From owner-freebsd-current  Wed May 22 19:04:40 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id TAA25992
          for current-outgoing; Wed, 22 May 1996 19:04:40 -0700 (PDT)
Received: from davinci.isds.duke.edu (davinci.isds.duke.edu [152.3.22.1])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id TAA25950
          for <current@FreeBSD.org>; Wed, 22 May 1996 19:04:26 -0700 (PDT)
Received: from diego.isds.duke.edu (diego.isds.duke.edu [152.3.22.47]) by davinci.isds.duke.edu (8.7.4/8.6.9) with ESMTP id WAA05227; Wed, 22 May 1996 22:04:14 -0400 (EDT)
From: Andrew Gallatin <gallatin@stat.Duke.EDU>
Received: (from gallatin@localhost) by diego.isds.duke.edu (8.7.4/8.7.1) id WAA24184; Wed, 22 May 1996 22:04:13 -0400 (EDT)
Date: Wed, 22 May 1996 22:04:13 -0400 (EDT)
Message-Id: <199605230204.WAA24184@diego.isds.duke.edu>
To: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Cc: current@FreeBSD.org
Subject: Re: NFS v3 problem 
In-Reply-To: <2563.832706377@time.cdrom.com>
References: <199605211613.MAA18122@diego.isds.duke.edu>
	<2563.832706377@time.cdrom.com>
Sender: owner-current@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk


Jordan K. Hubbard writes:
 > > 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. 
 > 
 > I think the first step is to see what the differences between the v2
 > and v3 created versions of libblas.a are.  Then you can try and work
 > backwards to see what ar did to create the corrupt version of libblas
 > and, in turn, which NFS operation is going awry.

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.

So.. basically, it looks like, give or take a few bytes, the last 8
512-byte blocks of the file are not being written.  Where to go from
here?

BTW: Terry, I enabled NQNFS to no effect.  I don't think that DEC
supports the leasing extensions to V3, at least not as of DU 3.2c.

Drew