On Sat, Jun 24, 2000 at 02:43:17PM -0400, John Hawkinson wrote:
> 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.

I consider that when the bad block map is filled, the drive is dead (if it has
so much bad blocks then there's no reasons for it to stop getting new ones).

> 
>    b)	  bad-block mapping by the hardware is transparent and there is
> 	  little visiblity into it. When it fails (i.e. one continually

This is what SMART is for IDE drives, I'm not sure about SCSI.

> 	  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.
> 
>    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.

Then we should port bad144 to SCSI and other supported disk types ?
Also note that there's severe performances penalty with bad144, as it has
to work in single-sector mode.

--
Manuel Bouyer <bouyer@antioche.eu.org>
--