Possible uda50 driver problem

Chris Torek chris at umcp-cs.UUCP
Mon Sep 8 12:07:13 AEST 1986


[Some of this is being taken off line.]

In article <194 at miduet.gec-mi-at.co.uk> steve at gec-mi-at.co.uk
(Steve Lademann) writes:
>With regard to bad block replacement [on UDA50s] ... from what
>I've seen with regard to the bad block replacement algorithms,
>there is a lot of Black Magic involved in the process anyway.

Not really.  The idea is very straightforward: save the original
data, allocate a replacement block, test it, copy the original data
to it, and mark the original block as forwarded.  The ugliness is
all caused by state saving for error recovery---our old friend the
commit. . . .  The problem gets worse if the forwarding code is
outside the driver.  What happens if the machine crashes during
forwarding?  (If the driver does things with the block half-forwarded,
who knows what might happen.)

>What will your solution to the problem of getting rid of bad blocks be
>(if any)? I must admit that after your comments with regard to the 'iffy'
>algorithm in the RIACS driver, mine could well be to call Field Service!

Well, actually . . . yes.  At least for now.

If you have a copy of Ultrix 1.1 or later, you can run `rabads';
it is a standalone program that just forwards bad sectors.  I have
never used it myself.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at mimsy.umd.edu



More information about the Comp.bugs.4bsd.ucb-fixes mailing list