Subject: bad144, take two
To: None <current-users@netbsd.org>
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
List: current-users
Date: 07/16/2001 15:23:57
So, my recent disk problems have led me to take a closer look at bad144.
I've discovered the following things:
a) You need to set the "badsect" flag using disklabel. Very important!
b) bad144(8) hasn't really changed much since the initial 386BSD import
back in 1993.
c) On the i386, bad144(8) uses the end of the C partition, _not_ the D
partition ... but only if the first partition is offset from the
beginning of the disk by a non-zero amount (I guess that's the 32
sectors you leave as room for the MBR and disklabel). This comment
still has "wfj" on it, so I'm guessing that it's been that way for
quite a while :-)
d) Some ports actually seem to have disklabel support for bad144. By my
reckoning, these include:
algor
alpha
arc
arm
bebox
cobalt
hpc
i386
prep
sandpoint
sh3
walnut
x68k
x86_64
These all seem to have copied the same chunk of code from the i386 port.
_That_ chunk of code dates way back from revision 1.1 of disksubr.c,
with the comment from Theo: "There will be niggly little details no doubt.."
I'm forced to conclude that this couldn't really have worked ... ever, at
least on the i386 if you've got a DOS and Unix partition on the same drive.
So anyway, I'd like to try to clean this mess up. It seems to me that
this would be the sane course of action:
- Fix bad144(8) on the i386 so it agrees with the disklabel method of
calculating the location of the error table. I think at the end of
the disk (rather than the end of the c partition) is a more
reasonable place for it.
- Clean up the man page so people can understand how to use it.
- Add support for bad144 remapping to SCSI devices. Now, I can understand
people that say that since SCSI drives do this in hardware, it shouldn't
be necessary ... but this has pulled my chesnuts out of the fire on
other systems, and I can't really think how this could possibly hurt
SCSI devices.
- Work with the sysinst gang to have sysinst have the option to automatically
reserve space for a bad144 track and optionally run bad144 at install time.
Now, if there's a giant outcry, and people think that bad144 should die
a horrible death, then that's fine ... but I'd prefer that in _that_ case,
we should just remove the damn thing so people don't think that it actually
works and waste time with it.
Questions? Comments?
--Ken