NFS bugs - consider this

[William Roberts;]

This posting from comp.protocols.nfs looks as though it might be directly 
relevant to the current discussion about A/UX and NFS problems. Could someone 
at Apple take a look at the source code for /bin/ld and find out if the lseek 
described below is actually used in ld? Then could they let us know?

>From: davecb at yunexus.YorkU.CA (David Collier-Brown)
>Organization: York U. Computing Services
>Date: 21 Feb 91 14:14:12 GMT
>Newsgroups: comp.unix.ultrix,comp.protocols.nfs
>Subject: Re: suspicious behavior of lseek() on NFS files

emv at ox.com (Ed Vielmetti) writes:
| What I'm seeing (Ultrix 4.1, Dec 3100) is that NFS mounted files
| sometimes read back nulls at the end of a growing file when the size
| is determined this way.  Almost as the the lseek(fd,0,SEEK_END) was
| zero-filling some cache somewhere with the wrong thing.  Note that on
| "real" unix filesystems this works just fine (45 mb/day read this way).

  This sounds a lot like a recurring Sun NFS problem: under unspecified
high-load conditions and large copies, blocks of files get randomly
filled with NULLs.
  Sun has said ``fixed in 3.2'' ... ``fixed in 4.1.1'' ad nauseam, but
the only reliable advice seems to be ``buy a faster machine''.  Someone
may be able to find more info in the sun-spots archives.
--

William Roberts                 ARPA: liam at cs.qmw.ac.uk
Queen Mary & Westfield College  UUCP: liam at qmw-cs.UUCP
Mile End Road                   AppleLink: UK0087
LONDON, E1 4NS, UK              Tel:  071-975 5250 (Fax: 081-980 6533)