%BACKUP-F-CLUSTER, unsuitable cluster factor redux

[Shriniketan Bhagwat]

Hi,

I remember, I was trying to take the BACKUP of larger disk on to a small disk where the cluster factor of the smaller disk was 1 or 2 where I saw the problem earlier. Below is what I tried to reproduce it.

$ DISMOUNT LDA10:
$ INIT LDA10: BACKUP2
$ MOUNT/FOR LDA10:
%MOUNT-I-MOUNTED, BACKUP2 MOUNTED ON _DADAR$LDA10:
$ BACKUP/IMAGE/LOG DKB200: LDA10:
%BACKUP-F-CLUSTER, UNSUITABLE CLUSTER FACTOR FOR LDA10:
$

In this case LDA10: is of capacity 10000 blocks and of cluster factor 1 and DKB200: is of capacity 71132960 blocks and of cluster factor 16. See attached file for $ show dev/full out put of both the disks. Here BACKUP is trying to initialize the disk LDA10: of capacity 1000 blocks with cluster factor 16 and fails with BACKUP-F-CLUSTER. Here in this case backup comparison of maximum blocks on LDA10: the DKB200: is reporting the error.

maximum_files_allowed is greater than volume_size / cluster_size + 1

I tried to initialize the disk LDA10: out side BACKUP through $ INITIALIZE command with /CLUSTER=16 qualifier and it is successful. For BACKUP, it has to copy the maximum files on source disk(DKB200:) to destination disk(LAD10:). Maximum files that LDA10: can handle is 294 and the DKB200: is 4184291. Creating 4184291 numbers of files on LDA10: is not possible. Hence BACKUP reports the BACKUP-F-CLUSTER error. It looks to me like it is an expected behavior.

$ DISMOUNT LDA10:
$ INIT LDA10: BACKUP4 /CLUSTER=16
$ MOUNT/OVER=ID LDA10:
%MOUNT-I-MOUNTED, BACKUP4 MOUNTED ON _DADAR$LDA10:
$

Later I created a LDA12: device of capacity 5000000 and of cluster factor 16 and then the BACKUP is successful.

$ LD CREAT REGRESSION5.ISO/SIZE=5000000
$ LD CONNECT REGRESSION5.ISO LDA12:
$ INIT LDA12: BACKUP
$ MOUNT/FOR LDA12:
%MOUNT-I-MOUNTED, BACKUP MOUNTED ON _DADAR$LDA12:
$ BACKUP/IMAGE/LOG DKB200: LDA12:

Regards,
Ketan

[Shriniketan Bhagwat]

Hi Brian,

This problem has been fixed in below Alpha kits. Please refer its cover letters.

VMS722_BACKUP-V0200
VMS731_BACKUP-V0100
VMS73_BACKUP-V0200

Regards,
Ketan

[BrianT_1]

> This problem has been fixed in below Alpha > kits. Please refer its cover letters.
>
> VMS722_BACKUP-V0200
> VMS731_BACKUP-V0100
> VMS73_BACKUP-V0200

Since a fix going back to OpenVMS V7.3 Alpha was issued, why not a fix for OpenVMS V7.3 VAX? Surely it wouldn't have been any more difficult?

Anyway, thanks a bunch for the ECO pointers. My Alpha currently runs V7.3-1, so I won't have to buy a new license.

Can anyone comment on the efficacy of my plan to use the Alpha as a backup engine so as to avoid the backup problem in my cluster? Does it sound to you like it will work?

[Jon Pinkley]

BT>Can anyone comment on the efficacy of my
BT>plan to use the Alpha as a backup engine so
BT>as to avoid the backup problem in my cluster?
BT>Does it sound to you like it will work?
---------------------------
Best would be to get a VAX version of a fixed BACKUP, but you already knew that.

Assumptions:

AlphaServer 1000 4/233 with VMS 7.3-1 (and VMS731_BACKUP-V0100 patch) and a VMSCLUSTER license. And direct access a compatible tape drive. You really don't want TMSCP served tapes and MSCP served disk over the same interconnect.

This will require that the VAX running 7.3 has a VAXCLUSTER license.

As long as the Alpha can access the disk, the it will "work", but I am not sure it would be better than a non-image restore on the VAX.

How will the Alpha access the raidset? If it is going to be MSCP served by the VAX, your performance will not be great. What is the cluster interconnect between the VAX and the Alpha?

Will an /image restore to an MSCP served driver be faster than an non-image restore on the VAX? This depends a lot on how many directories the 1283598 files are spread over, the more the better. Non-image restores enter each file into the directory using the XQP, where /image restores just copy the directory files as data. Even an image restore of a disk with 1283598 files is going to be slow, and restoring to a RAID-5 device will be slower than to RAID-0 or RAID-1 device, although I am not sure that is the bottleneck. A backup/physical would be the fastest and would avoid your restore problem, but it won't allow a backup of the disk while it is mounted for use. But if you can dismount and take the disk offline for backup, then it would be an option since this isn't a system disk.

Do you have access to any alpha where you can restore the tapes using an /image and non-image restore and see how much difference there is in the restore time? If the /image restore is significantly faster, then it may be worthwhile trying to restore to an MSCP served disk, but if it isn't 3-4 times faster, then the gains you make may be overshadowed by the loss due to MSCP serving over a relatively slow interconnect. If the interconnect isn't at least 100 mbit, I would be very pessimistic about getting good restore times.

Jon

[Jon Pinkley]

Brian,

http://www.openvms.compaq.com/doc/73final/cletters/av-qsbvh-tet1.pdf

Cover Letter for Compaq OpenVMS Alpha and OpenVMS VAX Version 7.3
AV-QSBVH-TE
May 2001

http://h18000.www1.hp.com/info/spd/ is no longer valid, and I am not able to find an SPD for OpenVMS VAX 7.3

However, this is a serious problem for sites that have only VAX computers (or emulators). And the fact that it was reported in 2002 and never fixed seems inexcusable. Perhaps there were restrictions on system disk not using extended bitmap.sys files, but if so where is this documented?

Evidently backup was able to restore disks with extended bitmaps, but only if they were ODS5 (based on comment in this thread dated Oct 29, 2008 03:14:49 GMT).

See http://www.chem.hmc.edu/www_common/OVMS072/72final/6017/6017pro_029.html This is the OpenVMS System Manager's Manual (January 1999 OpenVMS 7.2)

This manual is a task-oriented guide to managing an OpenVMS system.

Revision/Update Information: This manual supersedes the OpenVMS System Manager's Manual, OpenVMS Version 7.1

Software Version: OpenVMS Alpha Version 7.2 OpenVMS VAX Version 7.2

in section 8.1.1.2 Disk and CD-ROM File Structures
----------------------------------------------------------------
Limits of Storage and Index File Bitmaps

In previous versions of OpenVMS, both storage and index file bitmaps were limited to 255 blocks. This size, in turn, limited a volume to approximately one million allocation units, or clusters. Larger disks were required to have a larger cluster factor to accommodate the limit; for example, a 9 GB disk required a cluster factor of 18.

Beginning with OpenVMS Version 7.2, the limits of storage and index file bitmaps have been increased as follows: Type of Bitmap Limit
Storage bitmap 65535 blocks
Index file bitmap 4095 blocks

The increased bitmap limits have the following advantages:

They allow you to use space more efficiently with small files.
They increase the number of files allowed on a volume to the architectural maximum of approximately 16 million.

The behaviors of the INITIALIZE and BACKUP commands reflect the larger bitmap sizes. Refer to the OpenVMS DCL Dictionary for INITIALIZE command details and the OpenVMS System Management Utilities Reference Manual for BACKUP utility details.

Message Displayed with Earlier Versions

The following message is displayed on pre-Version 7.2 systems when you attempt to access a disk that was initialized on a Version 7.2 or later system:

%MOUNT-F-FILESTRUCT, unsupported file structure level

The increased size of the BITMAP field is incompatible with earlier versions of OpenVMS.

Check the size of BITMAP.SYS on the disk you want to access. If the size is 256 or greater and you want to access the disk from a pre-Version 7.2 system, you must copy the data to a disk with a BITMAP.SYS that is less than 256 blocks. If you use the DCL command BACKUP/IMAGE, be sure to use the /NOINITIALIZE qualifier.
----------------------------------------------------------------

Note Well the portion: "The behaviors of the INITIALIZE and BACKUP commands reflect the larger bitmap sizes."

Also note that the only place that mentions any restriction with needing to use BACKUP/IMAGE is when restoring to a pre-Version 7.2 system (in which case you must use /NOINITIALIZE).

So clearly, this is a bug in the implementation of BACKUP, and it should have been fixed with a patch to the VAX version of backup, especially since this was the last version ever released for the VAX.

Whether this worked correctly in OpenVMS VAX 7.2, I don't know. We know it did not work in 7.3. We also know there was a patch released for OpenVMS Alpha 7.3, but evidently one was never released for the VAX. I don't know how different the code base for the VAX version of Backup is than the Alpha version (I would assume there is a lot of common code, it is written in Bliss). Once the problem was fixed in the Alpha version, it seems that it would have been relatively straightforward to fix the VAX version as well. Perhaps it was done, but only released to specific customers that reported the problem and had a valid support contract.

Jon

[BrianT_1]

John Pinkley wrote:

JP> Will an /image restore to an MSCP served
JP> driver be faster than an non-image
JP> restore on the VAX?

Beyond a doubt because I've had to use a non-image restore twice now and it turned a job that would have taken about four hours into a job that took five days.

The Alpha connects with the VAXes via Ethernet (10MB Full Duplex), using TMSCP and MSCP for the tapes and disks. Even with served devices, an image restore should be significantly faster than a non-image restore.

[Jon Pinkley]

Just curious, where did the "four hour" estimate for the /image restore come from? Is that the time it takes for the image backup to tape?

[BrianT_1]

JP> Just curious, where did the "four hour"
JP> estimate for the /image restore come
JP> from? Is that the time it takes for the
JP> image backup to tape?

The estimate comes from that and from how long it takes to restore a disk the size of one of the RAIDset members. While four hours may be optimistic, an image restore would still be significantly faster than a file-by-file restore.

[Ian Miller.]

Brian,
can you post the result of these commands

$ ANALYZE/IMAGE/SELECT=(ARCH,FILE,NAME,IDENT,BUILD,LINK) SYS$COMMON:[SYSEXE]BACKUP.EXE;
$ ANALYZE/IMAGE/SELECT=(ARCH,FILE,NAME,IDENT,BUILD,LINK) SYS$COMMON:[SYSLIB]BACKUPSHR.EXE;

To show exactly which version you have.

[BrianT_1]

IM> can you post the result of these commands

For OpenVMS VAX, I have:

SYS$COMMON:[SYSEXE]BACKUP.EXE;1
OpenVMS VAX
Image
"BACKUP"
"V7.3"
""
16-MAR-2001 03:08:14.95

SYS$COMMON:[SYSLIB]BACKUPSHR.EXE;1
OpenVMS VAX
Image
"BACKUPSHR"
"V7.3"
""
16-MAR-2001 03:03:16.95

On the Alpha, I just installed DEC-AXPVMS-VMS731_UPDATE-V0600--4.PCSI so it has

SYS$COMMON:[SYSEXE]BACKUP.EXE;1
OpenVMS Alpha
Image
"BACKUP"
"AXP731R006"
"XA2Q-0060030008"
16-SEP-2004 15:26:36.32

SYS$COMMON:[SYSLIB]BACKUPSHR.EXE;1
OpenVMS Alpha
Image
"BACKUPSHR"
"AXP731R006"
"XA2Q-0060030008"
16-SEP-2004 15:26:29.20

From what has been posted in this thread, the Alpha version should not contain the bug. The Alpha is not in the same cluster right now as the VAXes accessing the raidsets whose bitmap exceeds 255 blocks. It is that Alpha that I said I intended to move from the cluster where it is to the cluster that requires the ability to restore the large bitmaps.

[BrianT_1]

BT> The Alpha is not in the same cluster
BT> right now as the VAXes accessing the
BT> raidsets whose bitmap exceeds 255
BT> blocks. It is that Alpha that I said I
BT> intended to move from the cluster where
BT> it is to the cluster that requires the
BT> ability to restore the large bitmaps.

Right now, this Alpha has a 10mb/Full ethernet card in it. If I use the Alpha aas a backup engine, is there a 100mb Ethernet card I can use that OpenVMS V7.3-1 will recognize so that I get better backup speeds?

[BrianT_1]

BT> The Alpha is not in the same cluster
BT> right now as the VAXes accessing the
BT> raidsets whose bitmap exceeds 255
BT> blocks. It is that Alpha that I said I
BT> intended to move from the cluster where
BT> it is to the cluster that requires the
BT> ability to restore the large bitmaps.

Right now, this Alpha has a 10mb/Full ethernet card in it. If I use the Alpha aas a backup engine, is there a 100mb Ethernet card I can use that OpenVMS V7.3-1 will recognize to that I get better backup speeds?

[Ian Miller.]

I expect a DE500-AA or DE500-BA will work in your alpha. A DE600 would be OK too.

[BrianT_1]

IM> I expect a DE500-AA or DE500-BA will
IM> work in your alpha. A DE600 would be OK
IM> too.

According to dectrader.com, the DE500-AA is compatible with an AlphaServer 1000, which is what my Alpha is, but the DE500-BA is compatible with an AlphaServer 1000A and that doesn't match my Alpha. Reading information on the DE600 at hp-store.com wsays that it replaces both the DE500-AA and -BA in all applications, but Google shows me part numbers DE600-AA and 3X-DE600-AA. What's the difference there? See this: http://www.calhountech.com/search/index.php?part=DE600-AA&gclid=CPLHveXdn6ICFREeDQodG30zwQ

[BrianT_1]

Oh, and what's the difference between a DE500-AA and a DE500-XA?

[Ian Miller.]

DE500-AA work, -XA don't :-)
See
http://labs.hoffmanlabs.com/vmsfaq/vmsfaq_025.html#supp9

For that vintage of hardware I would use a DE500-AA

[Jon Pinkley]

BT>Right now, this Alpha has a 10mb/Full ethernet card in it.
BT>If I use the Alpha aas a backup engine, is there a 100mb
BT>Ethernet card I can use that OpenVMS V7.3-1 will
BT>recognize so that I get better backup speeds?

Well it depends on what type of Ethernet controller is in the VAX 7730. I think the DEMNA-M is only 10Mbit, but Nemonix has a VAX XMI 100 Mb Ethernet Controller NXETHER-60.

So if you have a 100mbit Ethernet controller in the VAX already, then upgrading the Alpha to 100mbit would be relatively cheap (eBay), but if you don't already have 100mbit on the VAX, I doubt that upgrading the VAX would be cost effective, unless someone gave you the XMI ethernet adapter. FDDI would be another possibility, but not cheap unless you can find the adapters "free".

Jon

[Shriniketan Bhagwat]

Hi Brian,

Can you please log a support call with HP for this issue?

Regards,
Ketan

[BrianT_1]

JP> Well it depends on what type of Ethernet
JP> controller is in the VAX 7730. I think
JP> the DEMNA-M is only 10Mbit, but Nemonix
JP> has a VAX XMI 100 Mb Ethernet Controller
JP> NXETHER-60.

The 7730s have DEMNAs, as you surmise. I have a 4600A with a 100Mb Nemonix card, but we found they're not really suitable because the drivers don't load early enough for SCS traffic to flow at initial boot. I ran into situations where that cluster wouldn't boot without another ethernet card connected but I don't know if that's because I didn't have the 100Mb card configured correctly or something else. Once VMS got far enough along to load the drivers, it would work fine. Since those systems also had FDDI cards, we allowed SCS traffic to flow through that interface but directed other protocols like LAT and LAD over the 100Mb link.

JP> FDDI would be another possibility, but
JP> not cheap unless you can find the
JP> adapters "free".

The two 7730s have DEMFAs in them already, but my company's networking group is forcing me to disconnect them and revert to the DEMNAs because the FDDI switch to which they had been connect is not a managed switch and can't be placed on a separate VLAN. They will not replace the switch with another FDDI switch that could be managed because it wouldn't be "standard", so they're turning it off.

SB> Can you please log a support call with
SB> HP for this issue?

How does one do that absent a support contract? We employ on a time-and-marterials basis a local company that still has on their staff people who know the VAX hardware. I know of no way to place a support call to HP nor hope HP would act upon it if I knew how.

[Ian Miller.]

Brian,
if you emailed openvms.programs at hp
then they may assist. The people who read those emails are already aware of this thread.

[BrianT_1]

IM> if you emailed openvms.programs at hp
IM> then they may assist. The people who
IM> read those emails are already aware of
IM> this thread.

Then what more is there to do? They know the problem and they know the solution. What more could I possibly add?

[Jon Pinkley]

BT>The two 7730s have DEMFAs in them already, but my company's
BT>networking group is forcing me to disconnect them and revert
BT>to the DEMNAs because the FDDI switch to which they had been
BT>connect is not a managed switch and can't be placed on a
BT>separate VLAN. They will not replace the switch with another
BT>FDDI switch that could be managed because it wouldn't be
BT>"standard", so they're turning it off.

Do you have a PCI based FDDI card that will work in the Alpha (DEFPA)?

We used to have a thee node cluster (two ES40's and a AS2000) that used a FDDI in addition to 10BaseT Ethernet. The FDDI was "switchless", just two counter rotating rings between the 3 nodes (so every node could directly see both other nodes). So an FDDI switch isn't a requirement. But if you don't have a switch, and two nodes only, when you shutdown one of the nodes, and if you have DECnet running on the FDDI link, you will start to get adjacency down messages.

If the network group is abandoning the FDDI switch, can you just grab it for use as a dedicated private switch used only for the VMS nodes? As long as it isn't connected to anything else in the network, the networking group shouldn't be concerned.

Adding a DEFPA to the AS1000 would probably be the cheapest way to get a 100Mb SCS connection between the Alpha and the VAXes. I am not sure about the VAX, but for Alphas (7.x) , if the NISCS_MAX_PKTSZ was set to the FDDI size, then the FDDI would be used preferentially over the Ethernet, and for bulk data like backups, I would expect the larger packet size to be an advantage.

I hope that a patched version of the VAX backup is released. HP, that's the "right thing to do". It should have been done at the same time the patch was released for the Alpha.

Suggestion for HP, create a patch, have Brian be your beta tester, and then release the patch.

Jon

[BrianT_1]

JP> Do you have a PCI based FDDI card that
JP> will work in the Alpha (DEFPA)?

The Alpha already has a DEFPA in it, but as I said already, the networking group is decomissioning the fiber switch. That's why I had to revert to the 10Mb card and asked about the 100Mb twisted pair card. I can get a DE500-AA for $50.00 at Great Lakes Computers just up the street, so I'll replace the existing 10 Mb Ethernet card with that.

JP> I hope that a patched version of the VAX
JP> backup is released. HP, that's
JP> the "right thing to do". It should have
JP> been done at the same time the patch was
JP> released for the Alpha.
JP>
JP> Suggestion for HP, create a patch, have JP> Brian be your beta tester, and then
JP> release the patch.

That's what I think should be done also.

[Jon Pinkley]

BT>I can get a DE500-AA for $50.00 at Great Lakes Computers
BT>just up the street, so I'll replace the existing 10 Mb
BT>Ethernet card with that.

Adding a DE500-AA to the AS1000 4/233 is a good idea, since the Alpha will have its capabilities improved.

However, I don't see how doing that is going to improve the performance of the SCS traffic between the VAX and the Alpha, because the VAX is limited to 10Mb with the DEMNA. What am I not understanding?

Jon

[BrianT_1]

JP> However, I don't see how doing that is
JP> going to improve the performance of the
JP> SCS traffic between the VAX and the
JP> Alpha, because the VAX is limited to
JP> 10Mb with the DEMNA. What am I not
JP> understanding?

You're not missing anything. I'm going to price the Nemonix XMI add-in boards. I don't know if DEC/Compaq/HP had a 100Mb card for the VMI bus.