krstan@cbnewsc.ATT.COM (keith.r.stanley) (06/15/89)
I am looking for information on how to clean up a bad block table that has gotten extra entries. I can't find an option to either dump the contents of the table so I can use the 'enter or delete' option on the diagnostic disk or restart totally from scratch. I got into this condition by entering an incorrect number of cylinders for my external hard drive. I'd read the manual if possible, but there isn't much info that I can find on the options for the diagnostic disk. Thanks in advance. Keith Stanley att!ihlpy!krstan
jbm@uncle.UUCP (John B. Milton) (06/17/89)
In article <1256@cbnewsc.ATT.COM> krstan@cbnewsc.ATT.COM (keith.r.stanley) writes: >I am looking for information on how to clean up a bad block table >that has gotten extra entries. I can't find an option to either >dump the contents of the table so I can use the 'enter or delete' >option on the diagnostic disk or restart totally from scratch. > >I got into this condition by entering an incorrect number of cylinders for >my external hard drive. I'd read the manual if possible, but there >isn't much info that I can find on the options for the diagnostic >disk. This is my method. Backup everything (this will kill the entire disk and make UNIX unbootable, and worse). If you run this on a live system, god help you. I mean it. You better not have o+w on any /dev/*fp0[01]?. Ok for /dev/rfp02?. banner Kill > /dev/rfp000 Your disk is now "unformatted", so it has no bad block table, so the diagnostic disk will think it is a new disk and create a new, empty bad block table. What this really does is set the disk magic number in the VHB to something else, so the diag disk won't recognize it as formatted, and neither will iv, and you won't be able to reboot, the size of the disk is unknown, etc. The entire VHB, boot loader, and maybe part of inode table will be gone. My belief is once a bad block, always a bad block, so DO NOT DO THIS unless you have run into a similar problem as above. It is much safer to have extra bad blocks in the bad block table than it is to turn a squishy block loose in the file system. John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu (614) h:294-4823, w:466-9324; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform!