Re: Corrupted disk labels

[razzell%cs.ubc.ca@Warbucks.AI.SRI.COM (Dan Razzell)]

    Date: Wed 21 Feb 90 15:24:26-PST
    From: Mabry Tyson <tyson@ai.sri.com>

    Just a reminder:  If you have more than one Symbolics that use the same
    disk types, you can often mount the problem disk as, say, the second
    disk on a running Symbolics.

    If the failed disk only has worlds that you can rebuild or copy from
    somewhere else, you may just want to reformat, (if you might turn off
    the machine or didn't SCAN the disk flods, you should have the
    breath-of-life tape handy), rebuild the initial file system (which
    specifies where the bad blocks are) from the tape for that disk drive,
    load a world onto the machine, and go on from there.

    If the disk had LMFS files that you can't easily recover, you probably
    do want to try to recover without reformatting by swapping the disk
    to another machine (by cross-connecting the cables and all the other
    details (like unit select numbers)).

    Date: Wed, 21 Feb 1990 17:36:00 UTC-0800
    From: Kalman Reti <reti@stony-brook.scrc.symbolics.com>

    If you need to recover files from a partially broken LMFS, I have a
    prototype tool that I'd be glad to supply.

These are nice thoughts, but this is a standalone machine, and there is
no alternate disk I might use to boot Lisp.  That's why I was so
interested in knowing what could be done from the FEP.  The answer,
apparently, is reformat and little else, so by the time I get Lisp going
again, the old LMFS will be history.  It's a kind offer, though.

The standard FEP flod files that I have on cart don't provide any real
disk diagnostics, and the EMD368 drive doesn't have any status lights on
it, so I have no idea if the disk is dead, acknowledging SMD commands,
reporting faults or what.  I had hoped that someone would be able to
point to some diagnostic flods, or even that the FEP Disk Format command
had a nice little hammer in it for repairing bad labels, which I could
at least try before resorting to more destructive measures.  Sigh.  It's
hard to believe, given an architecture with a separate Front End
Processor, that nobody has thought of this before.