Subject: Re: kern/10430: Wd driver cannot handle bad144 table properly?
To: None <,>
From: Greg A. Woods <>
List: netbsd-bugs
Date: 06/25/2000 12:01:33
[ On Sunday, June 25, 2000 at 22:13:58 (+0900), Takahiro Kambe wrote: ]
> Subject: Re: kern/10430: Wd driver cannot handle bad144 table properly?
> In message <>
> 	on Sun, 25 Jun 2000 14:39:37 +0200,
> 	Manuel Bouyer <> wrote:
> > 
> > Then we should port bad144 to SCSI and other supported disk types ?
> I have a adapter which attach an IDE hard disk to SCSI interface.
> It confirms SCSI2 but I don't think SCSI's reassign block command
> works with it.
> So, bad144 might be useful but I also think we might create another
> type of software bad block mapping scheme.

Indeed I have a couple of ESDI-SCSI interfaces (both by Emulex, IIRC,
one 2-LUN unit from a Sun-3, and one 4-LUN unit from a 3B2).

ESDI drives do need manual re-mapping of bad sectors, and IIRC bad144 is
useful to work around a bad sector or two so that you can bridge over to
a time when you can afford to re-format the disk with a new bad-sector

I'm not sure what this means though....

I should also note that I've had some luck with some types of bad
sectors that I can simply gather up into a file I usually call /BAD on
the filesystem.  So long as you don't do full low-level dumps of the
disk and you can keep fsck from trying to read them, this is a workable
way of hiding such things.

A generic OS-level bad-block handling tool should not be called bad144
though -- IIRC that name relates directly back to the interface in
ST-506 drives and isn't even correct for ESDI.

I really liked the generic "hdelog" device driver and "hdelogger",
"hdeadd", and "hdefix" programs from AT&T UNIX.  Hard disk errors during
normal multi-user mode were automatically caught and logged and often
automatically remapped too.

							Greg A. Woods

+1 416 218-0098      VE3TCP      <>      <robohack!woods>
Planix, Inc. <>; Secrets of the Weird <>