Path: utzoo!attcan!uunet!samsung!umich!wsu-cs!ares.cs.wayne.edu!jjb
From: jjb@ares.cs.wayne.edu (Jon J. Brewster)
Newsgroups: comp.unix.ultrix
Subject: RA81 disk error/dump problem
Summary: Dump fails with more than 32 block read errors.
Keywords: ra81, dump, uerf
Message-ID: <1091@wsu-cs>
Date: 21 Feb 90 17:12:58 GMT
Sender: news@cs.wayne.edu
Reply-To: jjb@ares.cs.wayne.edu (Jon J. Brewster)
Distribution: na
Organization: Wayne State University, Detroit
Lines: 34

This concerns a uVAX3600 running Ultrix V3.1.  We've recently started
having problems with dump -- we get lots of bread messages with block
no.s and a final one that says "More than 32 block read errors from
64884"  Uerf shows many bad block replacement events for that disk, all
for the same LBN, 177837.  However, it also lists "PREVIOUS RBN 0." and
"NEW RBN 0.".  I assume that RBN means Replacement Block Number.  It
also says BAD BLOCK REPL CAUSE x0048.

A couple of puzzlements: when I do the icheck/ncheck two-step on the
block no.'s listed in the "(This should not happen) bread..." messages,
I find that the blocks are located in a very few files (i.e., many
blocks pointed at by far fewer inodes).  Further, the inode numbers are
almost consecutive.  Seems somehow reasonable.  However, icheck claims
that block 64884 is a free block.  So, what does that last message
indicate?

Second, I would hope that the problems uerf reports would somehow
relate to this, but I can't see any relationship between the LBN
and any of the bread errors.  Does anyone know the significance
of the RBN 0 lines?  The drive is an old one, left over from an 11/780
of yesteryear.  I wonder if the lines mean that it's incapable of
doing bad block replacement?  (I've run radisk on the disk, and
it seems to have no effect.  The -s option always gets caught in a
loop saying that LBN 177837 is replaced, and the -r option returns
with no message.)

Please e-mail me and I'll summarize if there's any interest.

TIA,

--
 Jon J. Brewster
 jjb@cs.wayne.edu
 ...!umich!wsu-cs!jjb