[ On Saturday, June 24, 2000 at 14:43:17 (-0400), John Hawkinson wrote: ]
> Subject: Re: kern/10430: Wd driver cannot handle bad144 table properly?
>
> It is unreasonable to expect automatic bad block mapping
> of drives to work reliably in all cases:
> 
>    a)	  bad-block maps can fill if disks are very bad. It is
>           still desirable to be able to use NetBSD on those disks,
> 	  and bad-block mapping should be possible at a higher layer.

Yeah, that's certainly possible -- time to toss the disk in the garbage
compactor at that point though....

>    b)	  bad-block mapping by the hardware is transparent and there is
> 	  little visiblity into it. When it fails (i.e. one continually
> 	  gets read errors on a given block), it is hard to know if the
> 	  bad-block mapping is broken, or if a) is in force, or some
> 	  unknown. Again, it is desirable to be able to recover from
> 	  this case.

yes, possible too, but again it's an indication of broken hardware (or
at least buggy firmware on the hardware, which ammounts to the same
thing) that desparately needs to be replaced.

This is pretty simple, but very low level, data integrity we're talking
about here -- you might as well use water-based inks on papyrus in a
monsoon if you don't replace known-to-be-broken hardware....

>    c)	  "Trust no one"; "Be liberal in what you accept and consrevative
> 	  in what you send."
> 
> bad144 should work in all cases, for these reasons.

I'm still not convinced.

(It should still work for those devices which cannot by design remap...)

> --jhawk
>   (who has had to use multiple nested ccds to make "holes" in his IDE disks
>   to avoid bad blocks because 1) bad144 didn't work 2) the drive did not
>   auto-remap, and is therefore bitter.)

Egads!  What masterful hackery!  ;-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>