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