Date: Wed, 22 May 1996 22:04:13 -0400 (EDT) From: Andrew Gallatin <gallatin@stat.Duke.EDU> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: current@FreeBSD.org Subject: Re: NFS v3 problem Message-ID: <199605230204.WAA24184@diego.isds.duke.edu> In-Reply-To: <2563.832706377@time.cdrom.com> References: <199605211613.MAA18122@diego.isds.duke.edu> <2563.832706377@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605230204.WAA24184>