From: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Newsgroups: comp.unix.ultrix
Subject: Re: Bad Blocks
Date: 9 Oct 92 19:55:49 GMT
Article-I.D.: nntpd2.1992Oct9.195549.21765
Reply-To: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Distribution: na
Organization: Digital Equipment Corporation


In article <BvtGt7.GD7@hsi.com>, geiste@hsi.com (Doug Geiste) writes:
>
>I have an RD53 as a secondary drive and while performing a backup (dd), it
>tells me :
>
> DUMP: (This should not happen)bread from /dev/rra1a [block 2480]: count=8192,
>got=-1
>  [ etc, with different block numbers... ]
>
>Yet, when running fsck, it's fine. I have a Mvax II with ULTRIX 4.1
>RD54 is the primary drive. How can I declare these blocks as being bad?
>
Three short subjects come to mind.

1.  Fsck doesn't read all the blocks on a partition.  It only reads
    the ones that have file system information in them.  It doesn't
    read file data blocks.  Your bad blocks are probably data blocks.
    Dump by necessity does read all the data blocks.

2.  The RD54 uses the RQDX controller family, probably the RQDX3 in
    your case.  This controller does it's own bad block replacement.
    Odds are, the block has already been replaced.  Why you're still
    getting I/O errors depends on understanding Forced Error.

3.  Forced Error.

When you read a block one of three things will be the case; the block
is good, bad or correctable.  If the block is good you have nothing
to worry about.  If not perfectly good, the block can still be corrected.
The RD54 has some extra bits that are used for error correction.  Finally
the block can be so bad that it can't be corrected.  In the case of the
RQDX3 when it gets an uncorrectable block it will automatically get
a replacement block.  The problem is that the data it has is the WRONG
data since it was able to correct it.  Rather than simply write the
wrong data back so there will be SOMETHING there, it marks the block
as having a "Forced Error".  The block is fine, but the data is corrupted.
When you try to read the block you'll still get an I/O, but the error log
will probably distinguish between it being an I/O error or a Forced error.

As soon as you rewrite the block, this will clear the Forced Error.  You
can also clear the Forced Error with radisk(8).  First make a note of
what blocks are corrupted so you can track down what files are now
broken later, then clear the error.  Use icheck(8) and ncheck(8) to
track back from block numbers to files.

Finally, it's worth pointing out that most MSCP controllers will still
arrange to do BBR when there are "too many" errors, but the data is
still correctable.  This way the block gets replaced and the corrected
data is written back.  "Too many" depends on the controller.

>Thanks.
>
>
>-- 
> Doug Geiste                           ||   "We are all faced with a series
> 3M Health Information Systems         ||    of great opportunities brilliantly
> ...!uunet!his!geiste                  ||    disguised as impossible situations"
> geiste@hsi.com                        ||
>
--
Alan Rollow				alan@nabeth.cxo.dec.com
Newsgroups: comp.unix.ultrix