Help with "NFS server write failed"

[Wayne Lyle]

In article <273a2efb.3d02 at petunia.CalPoly.EDU> booga at polyslo.CalPoly.EDU (Steve Jankowski [nectary]) writes:
>
>
>In article <292 at sgfb.ssd.ray.com> ras at 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