> As a temporary solution, maybe.  However, bad blocks are not supposed
> to be an issue with MSCP disks; the controller is supposed to hide
> such evil from the rest of the system.  This even holds for RX50
> floppies, actually.  :-)  The Right Thing when an MSCP disk shows up
> bad spots would be to use badsect(8) to trap them until a reformat can
> be performed.  (I don't believe MSCP controllers can dynamically remap
> bad blocks, in general.)

Yes, they can. If an MSCP controller finds a bad block, it is supposed to
try _really hard_ to get the data from the block and move it to a replacement
block. If the controller can get the data, the computer doesn't know anything
happened (well, RT-11 folks will notice in a couple of ways; since the
filesystem is contiguous, there'll suddenly be extra time involved in reading
a file with a bad block. The controller also requires time to discover and
read the bad block tables on a bus reset, which RT-11 does all the time.
Rumor has it that if you have more than 18 entries in the bad block table, 
an RQDX3 will take a noticeable performance hit here); whenever the
computer references the block, it will get the replacement block.

If the controller cannot get the data from a bad block, it is supposed to 
replace the block and mark the replacement block as a "forced error" block;
reading the replacement block will return an error (since the controller
couldn't get the data, what else should it do?). You should be able to
write the block, however; the data will be written to the replacement block.

On VAXstation 2000s running VMS, the device driver is responsible for 
performing the bad block dance normally done by the controller; the theory
is that the VMS device driver is supposed to behave like an MSCP controller
so overlying software doesn't know there isn't an MSCP controller. The dance
gets pretty complicated as the driver tries to ensure data isn't lost if
the machine goes down while trying to replace a block...

Roger Ivie
ivie@cc.usu.edu