 |
The Question is:
I had an annoying issue the other day. I just upgraded our AS 800 from OVMS
7.2-1 to 7.3-2. For the upgrade, I created a dir on the userdisk(dka100:) to
hold all the patches for 7.3-2 as below.
$ create/dir dka100:[system]
I downloaded several patches such as:
VMS732_UPDATE-V0200
DEC-AXPVMS-TCPIP_ECO-V0504
VMS732_DCL-V0200
VMS732_LIBRTL
...
When I tried to do an image backup of the userdisk, the dev (dka100:) went
offline and went into a mountverify loop. I tried this twice and both times
the backup made it to the dka100:[system] dir that I had created and then went
offline. I then booted mi
n and did anal/disk/repair dka100: and it was clean. I then mounted the disk
privately and tried backup dka100: mkb600:.... and the same thing happened. I
then deleted the dir and all patches and the image backup ran just fine. My
question is, was it the
dir [system] or the patches the caused the device to go offline? I can try and
get a test box to test this on but just wanted your thoughts.
Thanks in advance.
The Answer is :
Mount verification is the expected OpenVMS response to retryable I/O
errors.
Please contact your prefered hardware support organization, or HP
services. The most common causes of mount verification errors are
transient hardware errors, though there are also cases where more
serious hardware errors -- or occasionally even software errors --
have triggered mount verification errors.
Mount verification occurs when an error that is deemed retryable and
potentially fixable is returned on an I/O. There can be controller
and network-level reconfigurations that cause transient connectivity
losses, and an I/O occuring during such an outage will trigger the
mount verification (MNTVER) processing -- at least one older disk
storage subsystem had a fixed disk and a removable disk on the same
spindle and motor assembly, and spinning down to remove the removable
disk platter would trigger mount verification. There are other
potential triggers -- mount verification can also be triggered by
hardware problems.
Details on instances of hardware errors can generally be retrieved
from the system error log.
As an obvious precaution -- should this be triggered by a failing
disk spindle or other failing storage hardware -- please perform a
full disk BACKUP/IMAGE operation of any critical data.
Related discussions include (2602), (3277), (4680), (6685), (6745),
(7033), (8101), (8764), (9036), and (9095).
|
|
|
|
|
