>	IDE drives normally handle mapping bad blocks internally - the
>	fact you've seen a bad block probably indicates that its run out
>	of space to map out blocks - that disk could really be a dyin'...

IDE drives, at least those that use the same firmware as their SCSI cousins,
will automatically replace a bad block *if and only if* they know what data
to put in the replacement block!  If the sector is discovered bad during a
write, that's not a problem; but on a read, the error has to be recoverable
(but bad enough that it's worth mapping; typically drives have a quick-retry
scheme and a heroic-measures scheme, the latter causing a remap if it succeeds
in rescuing the data from the jaws of death).  After all, would you rather get
an error message when reading a file -- or a sudden (and silent!) pile of
zeroes instead of data?  With the message, at least you *know* what files
are corrupted.

The SCSI standard gives well-described mechanisms for forcing the mapping of
sectors, so there are lots of utilities that will do that manually.  IDE is,
of course, nowhere near as well standardized, but I think ATAPI borrows
pretty heavily from SCSI and probably ensures that generic formatters for
modern EIDE drives are possible (but probably only run under DOS).
Formatting the drive will also (sometimes) cause the block to get mapped
out, but unfortunately all too often the failure is pattern sensitive and
the format process on modern disks no longer does a useful certification
check.  (This also assumes you don't have one of the older IDE drives which
were rendered useless by a format because their microcode authors weren't
smart enough to be careful when formatting the microcode tracks...)