Mount Verification Error After Analyze /Repair

[Jeffery D. Urmann]

Hello All,

I routinely perform $Analyze /Disk /Repair, on disks as part of normal maintenance on all disks. The other day, I just happened to do an $Reply /Enable = Disk, prior to Analyze. And every time I perform the repair operation on an SWXCR disk (all are shadow sets), the disk would go into mount verification. The verification completes immediately It does not happen on my HSZ40 disks nor on the KPSA disks. The mount verification only occurs with the repair qualifier on the SWXCR.

What could be wrong? Or is this expected behavior on SWXCRs? Am I sitting on a time bomb?

System: OpenVMS 7.3-1 on an DS20 dual 500 Mhz.

Enjoy,

--Jeff

[Ian McKerracher_1]

Jeffery,

The System Management Utilities Reference Manual for V7.3-2 states that "When you update the storage control block (SCB) within a BITMAP.SYS
file, the VERIFY utility forces the volume to perform mount verification if
the volume is controlled by host-based shadowing".

Now, your Analyze/Disk/Repair can call upon the VERIFY utility behind the scenes. This could be what is happening in V7.3-1. So, in answer to one of your questions, I suspect that this is expected behaviour.

V7.3-2 introduced quieter mount verification. The following is from the V7.3-2 New Features and Documentation manual "Quieter mount verification suppresses the messages that previously were displayed for mount verification events from which the devices immediately recovered. These messages alarmed some customers".

Hope this helps,

Ian

[Robert Brooks_1]

To elaborate on the previous note:

Suppression of certain mount verification messages is controlled by the SYSGEN params MVSUPMSG_INTVL and MVSUPMSG_NUM. The documentation gives a reasonable explanation of how these parameters work.

Some background -- as part of multipath path switching, mount verification is entered (for both a manual path switch [$ SET DEVICE /SWITCH /PATH = ] or an automatic path switch [due to an I/O error]). Typically, the mount verification messages due to path switching are quite benign, but some customers become somewhat concerned, so we decided to "hide" the messages by default. We suppress messages where the mount verification event is resolved almost immediately. If there is truly a problem, we will faithfully emit a message to OPCOM.

[Andy Bustamante]

The SWXCR was nifty little raid controller, but at times not very bright. Do you have the SWXCR utility installed?

$ SWXCR MONITOR device_name

will start a monitoring process that will send OPCOM messages for any device not in an optimal state.

Andy

[Volker Halle]

Jeff,

ANAL/DISK is the VERIFY utility - just type CTRL-T when running it.

SET VOL/REBUILD=FORCE on a shadowset will also put the device into mount-verification shortly. The same thing would also happen on MOUNT/REBUILD.

The ACPCONTROL function FORCE_MV is used to force mount-verification and the SCB is re-read to make sure, that it has been successfully updated on disk.

Volker.

[Jeffery D. Urmann]

Thank you all for such great responses. I really appreciate it. I will put the Kevlar away and I will sleep tonight.

Ian,
Your suspicions appear to be confirmed by the well respected ITRC experts.
---^

Robert,
Since I did not change the defaults, and I do not believe I am doing path switching, and this OPCOM message only appears on SWXCR shadow sets, why is it "suppressed" or not "activated" on my other controllers' shadow sets? Does this indicate that there is "truly a problem?" Or is the SWXCR just taking longer to respond and triggers the mount verification? Or...? (bad cable, SW I/O module, SWXCR...)

As soon as I find the documentation, it`s on a CDrom here somewhere...
---^

Andy,
All drives are optimal.

Yes, I had the monitor running in the past. I had it EMail me as well as OPCOM. But...I quiesce the data on the shadow set, dismount a shadow member, back it up, mount it back into the shadow set. I have shut down the monitor as it "locks" a channel on the first drive (dr0:) and can not be dismounted.
---^

Volker,
So, I infer that the ACPCONTROL function FORCE_MV is used at some point by the repair operation of the Verify utility?
---^

Thanks again everybody.

Enjoy,

--Jeff

[Aaron Lewis_1]

Jeff, you can specify which device to lock when you start the monitor.

SWXCR MON/LOG DRAX:

We ran SWXCR drives for a number of years, and the monitor almost always picked up a pending device failure well before VMS started logging errors, and before it failed completely.

I would highly recommend that you re-enable the monitor on a different device, or do your backups from a 'non' 0 drive.

[Volker Halle · Accepted solution]

Jeff,

during the /REPAIR operation, the QUOTA_CLEANUP routine forces a mount-verification to synchronize the updated SCB (Storage Control Block) contents with shadowing.

Volker.

[Jeffery D. Urmann]

Aaron, Thanx. Yes, I know, but I backup all drives on the SWXCRs.

Volker, Okay, I believe what you are saying. Thank you for your continued assistance.

Out of curiosity, why does the OPCOM message either "suppress" or not trigger on non-SWXCR controllers?

Enjoy,

--Jeff

[Volker Halle]

Jeff,

are your HSZ and KxPSA disks also shadowsets?

Volker.