--My original post
Can any one tell me what this means. I never saw this until I
upgraded to 3.2. I also did a little disk movement. (put var
on its own partion) How do I find out what device is 0,0?
I am getting a lot of these. (7 to 10 in the time it took me
to write this note)
UBC write error(2) on device (0, 0) at block 0 size 8192
--end of post---
I received two, me toos and one informational message. My system
has been up for 12 days now, no problems that I have noticed. ;)
Thanks alan.
Rene
------------------------------------------------------------
From: MX%"alan_at_nabeth.cxo.dec.com" 16-MAR-1995 21:15:45.81
Odds are 0,0 is the console, but use:
ls -l /dev | grep " 0,"
to be sure. One of the problems that UNIX systems have
with delayed writes, is that there's no way of knowing
who to report an error to, if one occurs. I think most
systems just kept the buffer dirty in the hope that it
would be written eventually. But it would do this
quietly. It looks like V3.2 is making a bit of noise
when a delayed write fails.
In the general case this is a reasonable explaination
for the error. But if the (0,0) is the console, it seems
a bit odd. One of two things comes to mind:
o A bug in the error reporting code that it get the
device number (and possibly LBN wrong). LBN 0
is typically reserved for the disklabel which most
things should know better than to write.
o Something is writing 8 KB to /dev/console through
the unified buffer cache and for whatever reason the
write fails. Being optimistic that the write can
succeed eventually, the buffer stays dirty and gets
retried occassionally.
The first is a bit obscure, but possible. I can't think
of a way for the 2nd to occur, but with more stuff wanting
to go through the UBC I could just be not imaginative
enough.
Received on Tue Mar 21 1995 - 17:51:02 NZST