Xref: utzoo comp.unix.ultrix:6305 comp.protocols.nfs:1807 Path: utzoo!utgpu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!davecb From: davecb@yunexus.YorkU.CA (David Collier-Brown) Newsgroups: comp.unix.ultrix,comp.protocols.nfs Subject: Re: suspicious behavior of lseek() on NFS files Message-ID: <21723@yunexus.YorkU.CA> Date: 21 Feb 91 14:14:12 GMT References: Organization: York U. Computing Services Lines: 20 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. --dave -- David Collier-Brown, | davecb@Nexus.YorkU.CA | lethe!dave 72 Abitibi Ave., | Willowdale, Ontario, | Even cannibals don't usually eat their CANADA. 416-223-8968 | friends. Brought to you by Super Global Mega Corp .com