 |
The Question is:
What is causing these errors? Is it a bad file? Is it a bad disk? Is there
any way to get this information off the disk or is it just gone?
The Answer is :
You will want to review the frequency and validity of your BACKUPs,
of course. You will also want to review the applicability of volume
shadowing (software mirroring) and controller-based RAID (hardware
mirroring) to your configuration.
All of the blocks located prior to the block containing the parity error
and potentially all of those blocks located after the error are probably
still valid. Perhaps you are lucky, and the corrupt block(s) did not
contain any user data, or did not contain unrecoverable or unrepairable
data. Or (unfortunately) perhaps not.
MUMPS supplies a utility to test integrity; perhaps it also includes a
facility for recovering from situations involving file corruptions.
Writing data to what are apparently flawed disk block(s) will cause disk
bad block revectoring to occur. Obviously, you will need to know what
data to write, or (if the contents are valid or are recoverable from a
BACKUP) being willing to rewrite the entire file.
You will also want to review the length, connectivity, and termination
of the SCSI bus involved -- you will want to ensure that the length is
as short as feasible and is as far below the specified maximum bus length
as can be reasonably achieved, that the bus is correctly terminated, and
that all SCSI devices and all SCSI controllers on the bus are correctly
configured and functioning correctly.
Details on disk bad block revectoring are in topic (6926).
The OpenVMS system error log likely contains more detailed information
on the disk (parity) error.
|
|
|
|
|
