![]() |
![]() HP OpenVMS Systemsask the wizard |
![]() |
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.
|