#D14@DDATHD21.BITNET (11/28/85)
Hi Daniel,
I've tried to send a direct my to you but your FROM field
doesn't contain a valid arpa address that is know at
WISCVM.WISC.EDU. I've tried four different address but there
was no success.
I've had a bitmap problem some time ago. I think V3.7 was running.
A defective block (parity error or fatal controller error or
something like these) in the bitmap write locked the disk.
The field service said they have to update the bad block file.
But their EV??? utility reformatted the whole tracks. So a lot
of blocks of the bitmap have been destroyed. I had to run
DEFINE SYS$OUTPUT OUT.LOG /USER
DEFINE SYS$ERROR ERR.LOG /USER
ANALYZE /DISK /REPAIR RP07:
to fix the write lock. The output is to be directed to a file
because thousends of error message are produced.
So do you have had some device errors after changing HDA ?
What has the field service done after restoring the disk ?
With kind regards
Reinhard Goeth @ Technical University Darmstadt, W.Germany, Europe
(Beware of the number-sign. It's part of my userid !!!)OC.PEDHEM@CU20B.COLUMBIA.EDU (Guy Talbot) (12/03/85)
----------------------------------------------------------------------------- To: <INFO-VAX@sri-kl.arpa> Reference: 28 Nov 85 02:10 +0100 <#D14%DDATHD21.BITNET@wiscvm.wisc.edu> Subject: Bitmap problem We at Cooper Union recently had a bitmap problem on an RK07 without a recent backup. This particular pack was so badly damaged that it would not mount even with /OVER=(LOCK). Since the data was important (isn't it always), we tried an interesting recovery procedure: 1. Backup /physical the pack to tape: $MOUNT DMA0:/FOR $MOUNT MSA0:/FOR $INIT MSA0: RECOVR $BACKUP/PHY DMA0: MSA0:ADMIN.BCK/comm="The remaining blocks" 2. Roll the Physical backup onto another blank and BAD'ded pack: $MOUNT DMA1:/FOR $BACKUP/PHY MSA0:ADMIN.BCK DMA1:/REW 3. Errors about bad blocks not matching occured but as long as the bad blocks don't overmap what you need so what. 4. MOUNT the new pack with /OVER=(id). 5. Backup file-by-file the new pack to tape PARITY errors will probably occur where bad blocks on the new pack overmap bad blocks on the old pack. 6. If parity errors occur on any critical files repeat the procedure on another blank and BAD'ed pack. This sequence allowed us to recover our critical data and recreate the original pack. We created the original pack from the file-by-file backup of the new pack. It probably best to re-BAD (or EVRAC) the pack after after you have extracted the files as the BAD block info is probably messed up. Chris Lent Care of OC.PEDHEM@CU20B CUPHOA::LENT (VAXmail) (203) 452-1522 (Ans. Machine) ----------------------------------------------------------------------------- -------
McGuire_Ed@GRINNELL.MAILNET (12/05/85)
It was mentioned here recently that disks that were otherwise unmountable could sometimes be mounted if the disk was PHYSICALLY write-locked.