topic Re: MOUNT-F-MBRTOOSMALL in Operating System - OpenVMS

MOUNT-F-MBRTOOSMALL

Joe Hoggood — Thu, 14 May 2009 17:28:49 GMT

I had an OpenVMS AXP 7.3 mirror set (OpenVMS Volume Shadowing) called DSA1: working just fine with 2 x RZ28 members (DKB100/DKD100) until I upgrade to OpenVMS 8.3 then the mirror set will no longer allow DKD100 to join. Here's the MOUNT command and corresponding error:

$ MOUNT/NOMOUNT_VERIFICATION/NOASSIST/SYSTEM DSA1: /SHADOW=($1$DKB100:, $1$DKD100:) User_1 User_1
%MOUNT-I-MOUNTED, USER_1 mounted on _DSA1:
%MOUNT-I-ISAMBR, _$1$DKB100: (GRED28) is a member of the shadow set
%MOUNT-I-SHDWMEMFAIL, _$1$DKD100: (GRED28) failed as a member of the shadow set
-MOUNT-F-MBRTOOSMALL, must be the same size or larger than logical volume size

Any help would be appreciated!

Re: MOUNT-F-MBRTOOSMALL

Hoff — Thu, 14 May 2009 17:55:28 GMT

SHOW DEVICE /FULL on each of the two disks, please?

Is the box current on ECO kits for OpenVMS Alpha V8.3?

What are the SCSI controllers involved here, and what other gear here is (also) in allocation class 1 in the cluster?

Also look to replace the RZ28 drives; replacement SCSI disk widgets here are cheap, are newer, and also have larger capacities.

Re: MOUNT-F-MBRTOOSMALL

marsh_1 — Thu, 14 May 2009 17:59:12 GMT

hi,

can you post up a sh dev/full for the disks involved here.

hth

Re: MOUNT-F-MBRTOOSMALL

cnb — Thu, 14 May 2009 18:06:27 GMT

Joe,

Apologies for asking the obvious, but what are the two rz28 drives physical block sizes for DKD & DKB?

There were different flavors of 2GB disks that DEC used for RZ28x-xx and not all were the same exact size.

hth,

Re: MOUNT-F-MBRTOOSMALL

Robert Brooks_1 — Thu, 14 May 2009 18:26:46 GMT

MOUNT/NOMOUNT_VERIFICATION

--

Why don't you want mount verification?

There are very few reasons why you'd ever want to do that.

-- Rob

Re: MOUNT-F-MBRTOOSMALL

Hoff — Thu, 14 May 2009 18:37:39 GMT

If you use the DVE (dynamic volume expansion) and (particularly) DDS (dissimilar device shadowing) features of OpenVMS, and you get the small disk brought online first, then you can operate with devices of different sizes.

As others have stated (and it is why we're all asking for the block size via SHOW DEVICE /FULL or otherwise), the block count is a key here.

Similarly, depending on the particular SCSI controllers here, there can be size differences presented up to the OpenVMS host; some RAID controllers can present "non-transportable" (with metadata) and "transportable" (without metadata) disk configurations.

For comparison purposes, current single-spindle disks are now available with 1 and 1.5 and 2 terabyte capacities. OpenVMS can address that first of these, but the second and third are beyond the 31-bit addressing limits of the current ODS-2 and ODS-5 file systems.

Re: MOUNT-F-MBRTOOSMALL

Jan van den Ende — Thu, 14 May 2009 19:15:11 GMT

Joe,

_IF_ DSA1 has not yet been modified, _THEN_ this situation can be overcome by
- DISMOUNT DSA1
- MOUNT /SYSTEM DSA1: /shadow=$1$DKD100 [...] ! ONLY the member that reportedly was the smaller
- MOUNT DSA1: /SHAD=$1$DKB100: ! add the larger mem ber

The cost: lost of all modifications since the upgrade and the time of a full copy.

... if this was the system disk, then things are somewhat more complicated; the dismount involves shutdown and the boot should be from the second member.

hth

Proost.

Have one on me.

jpe

Re: MOUNT-F-MBRTOOSMALL

Joe Hoggood — Fri, 15 May 2009 15:30:13 GMT

Had to rebuild GRED28 RZ28 virtualized disks as follows to get around the mismatched logical volume sizes reported after upgrading to OpenVMS 8.3:

All block/buffer sizes are 512.

- Since these are virtual RZ28's I simply created new RZ28 (2GB) virtuals for DKD*.

- Then Windows file copied those to DKD* to DKC*

- Standalone boot -> backup/image the original DKB* to new DKC*

- Renamed the DKC* virtual containers to DKB*.

- Reboot with mount/shadow ... worked fine.