liam@cs.qmw.ac.uk (William Roberts;) (02/26/91)
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@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@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@cs.qmw.ac.uk Queen Mary & Westfield College UUCP: liam@qmw-cs.UUCP Mile End Road AppleLink: UK0087 LONDON, E1 4NS, UK Tel: 071-975 5250 (Fax: 081-980 6533)