Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mcnc!gatech!ncar!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!sjuphil!wlyle From: wlyle@sjuphil.uucp (Wayne Lyle) Newsgroups: comp.sys.pyramid Subject: Re: Help with "NFS server write failed" Keywords: Pyramid, NFS Message-ID: <1990Nov11.190543.2211@sjuphil.uucp> Date: 11 Nov 90 19:05:43 GMT References: <292@sgfb.ssd.ray.com> <273a2efb.3d02@petunia.CalPoly.EDU> Reply-To: wlyle@sjuphil.UUCP (Wayne Lyle) Distribution: usa Organization: Saint Joseph's University Lines: 42 In article <273a2efb.3d02@petunia.CalPoly.EDU> booga@polyslo.CalPoly.EDU (Steve Jankowski [nectary]) writes: > > >In article <292@sgfb.ssd.ray.com> ras@sgfb.ssd.ray.com (Ralph A. Shaw) writes: >>For the past few days, we've been getting messages like: >> >>>NFS server write failed: (err=69, dev=0xf0648650, ino=0x2). >>>NFS server write failed: (err=69, dev=0xf0722bf4, ino=0x2). >>>NFS server write failed: (err=69, dev=0xf0648650, ino=0x2). >> >>every few seconds on our Pyramid 9820's console. Nothing obvious is wrong, >>there are no local or remote file systems that are above 90% full, >>but I am at a loss as to how to trace the dev= information to find >>which system has the problem. > >We've been getting similar messages since upgrading to 5.0, though >not very frequently. They remind me of the leftover debugging >statement that was left in 4.4. That message complained of an error >69 whenever a user wrote a block that put them over quota. Given >that we service 600 undergrads with about the same number of megs, >our console was often unusable... > >I digress. I suspect the message is caused by an NFS inspired write >that is putting the user over their quota. If you don't run quotas, >this prognosis is completely useless. This happens to us a lot (9825's 4.4c). Mostly when the PC running PC-NFS makes a big write. Time to time it will happen when our mac users (through a gatorbox) makes a write. We don't use quota's so it is that for us. It doesn't seem to corrupt anything, my guess is that it tells the client just to send it again. It is annoying and shocking to an unsuspecting operator. We are hoping to go to 5.0 soon. I hope that the reason you don't see the message any more is that it has been fixed, instead of disregarded. Wayne -- Wayne J. Lyle Dilworth, Paxson, Kalish & Kauffman Philadelphia, PA 19109 (215) 875-8583