Operating System - OpenVMS

Re: %BACKUP-F-CLUSTER, unsuitable cluster factor redux

 
SOLVED
Go to solution
BrianT_1
Regular Advisor

Re: %BACKUP-F-CLUSTER, unsuitable cluster factor redux

Still hoping for an update.
--
Brian Tillman
GuentherF
Trusted Contributor

Re: %BACKUP-F-CLUSTER, unsuitable cluster factor redux

All I can tell is it had been assigned to the BACKUP team a long time ago but no response so far. They must be very busy then...

/Guenther
BrianT_1
Regular Advisor

Re: %BACKUP-F-CLUSTER, unsuitable cluster factor redux

Should I assume that the BACKUP team never intends to address this bug in BACKUP? If that's the case, what approaches can I take? One that might be available to me is to join an AlphServer 1000 4/233 to the VAXcluster where the error is and use the Alpha version of BACKUP if I can verify that OpenVMS Alphsa V7.3-1's BACKUP doesn't contain the bug (I don't have legal access to any later versions of OpenVMS).
comarow
Trusted Contributor

Re: %BACKUP-F-CLUSTER, unsuitable cluster factor redux

First you said it works if you don't use the image qualifier? Is it the system disk?
If not, you can do a full backup.
Will it do a backup/list?



When does it fail?
BrianT_1
Regular Advisor

Re: %BACKUP-F-CLUSTER, unsuitable cluster factor redux

comarow wrote:

> First you said it works if you don't use
> the image qualifier? Is it the system
> disk? If not, you can do a full backup.
> Will it do a backup/list?

Please read the prior messages in this thread. I've covered the details already. BACKUP/IMAGE cannot be used to restore an ODS-2 volume whose BITMAP.SYS exceeds 255 blocks because, apparently, that value is hard-coded into BACKUP despite ODS-2 supporting 64K BITMAP.SYS files since V7.2. As I also said already, not using /IMAGE takes four full days to restore the RAID set I'm using of four 9.2GB RZ1C disks. Other aspects of BACKUP, like /LIST work fine and BACKUP/IMAGE also works just fine to create the unrestorable saveset. This is a major flaw in OpenVMS VAX BACKUP.
--
Brian Tillman
BrianT_1
Regular Advisor

Re: %BACKUP-F-CLUSTER, unsuitable cluster factor redux

Günther Froehlin wrote:

> All I can tell is it had been assigned to
> the BACKUP team a long time ago but no
> response so far. They must be very busy
> then...

Has fixing this fatal BACKUP error that would prevent the restore of a system disk bubbled up from the bottom yet?
BrianT_1
Regular Advisor

Re: %BACKUP-F-CLUSTER, unsuitable cluster factor redux

I need to revisit this thread again. While I have been able to recover from the problems described in it, I'd like to avoid them again in the future. One of the means I intend to use is using an ALpha running a VMS version that doesn't have the backup bug. Here's a quote of Günther Froehlin from one of the messages in this thread:

GF> I wonder whether there ever was an ECO
GF> to fix that in BACKUP on VAX. Fixed in
GF> the Alpha version.

What version of OpenVMS Alpha contains this fix? I want to purchase a license for that version and incorporate the Alpha I have into my VAXcluster, with the ALpha running the version of OpenVMS that has the fix. I'll then use the Alpha as a backup engine.

Also in this thread, Günther said:

GF> I opened an internal problem report with
GF> high priority because you may not be
GF> able to restore your system disk. Let's
GF> see how this goes. No promises!

I was wondering if there were any results of this. I realize, of course, that "no promises" means that, as I suspected, there's no real interest in fixing this bug, but one can always hope.
Shriniketan Bhagwat
Trusted Contributor
Solution

Re: %BACKUP-F-CLUSTER, unsuitable cluster factor redux

Hi Brian,

This problem was reported to engineering some times during year 2002 from the data what is available to me. This has been fixed in OpenVMS V7.3-2 SSB release. Also the fix is part of VMS731_BACKUP-V0200 ECO kit. Refer the below link for details.

http://ftp.uma.es/Vms/parches/v7.3-1/VMS731_BACKUP-V0200.txt

> What version of OpenVMS Alpha contains this fix? I want to purchase a license for that version
You can purchase any OpenVMS version which is higher or equal to V7.3-2. Since it has been fixed in V7.3-2 SSB, the fix will be available in all higher versions. Even higher versions will contain many more fixes and new features.

Regards,
Ketan
Shriniketan Bhagwat
Trusted Contributor

Re: %BACKUP-F-CLUSTER, unsuitable cluster factor redux

Hi,

As Hein said:
> Backup reports the error BACKUP$_CLUSTER under two circumstances:-
BACKUP code has the check for cluster factor against its lower bound such that the storage map does not exceed 65535 blocks and also check for a reasonable minimum number of clusters i.e. 50. BACKUP calculates maximum number of files on the disk based on number of cluster factor. This value is compared against the architectural limit. This true even in case of V8.4.


Regards,
Ketan
Shriniketan Bhagwat
Trusted Contributor

Re: %BACKUP-F-CLUSTER, unsuitable cluster factor redux

Hi,


I remember, I was facing the similar problem long back while taking BACKUP on to the LD disk having smaller cluster factor.
I tested the BACKUP to reproduce the problem by taking the image BACKUP of the disk containing the smaller cluster factor to the disk containing the larger cluster factor and vice versa. But I am unable to reproduce it. I tested this on V8.3-1h1 IA64. Below is the test log.

$ LD CREAT REGRESSION3.ISO/SIZE=10000/CONT
$ LD CONNECT REGRESSION3.ISO LDA10:
$ INIT LDA10: BACKUP
$ MOUNT/OVER=ID LDA10:
%MOUNT-I-MOUNTED, BACKUP MOUNTED ON _DADAR$LDA10:
$ SHOW DEV/FULL LDA10:

DISK DADAR$LDA10:, DEVICE TYPE FOREIGN DISK TYPE 1, IS ONLINE, ALLOCATED,
DEALLOCATE ON DISMOUNT, MOUNTED, FILE-ORIENTED DEVICE, SHAREABLE.

ERROR COUNT 0 OPERATIONS COMPLETED 405
OWNER PROCESS "_TNA58:" OWNER UIC [SYSTEM]
OWNER PROCESS ID 000010F4 DEV PROT S:RWPL,O:RWPL,G:R,W
REFERENCE COUNT 2 DEFAULT BUFFER SIZE 512
TOTAL SIZE 4.88MB SECTORS PER TRACK 10
TOTAL CYLINDERS 100 TRACKS PER CYLINDER 10
LOGICAL VOLUME SIZE 4.88MB EXPANSION SIZE LIMIT 6.00MB

VOLUME LABEL "BACKUP" RELATIVE VOLUME NUMBER 0
CLUSTER SIZE 1 TRANSACTION COUNT 1
FREE SPACE 4.83MB MAXIMUM FILES ALLOWED 2500
EXTEND QUANTITY 5 MOUNT COUNT 1
MOUNT STATUS PROCESS CACHE NAME "_DADAR$DKB200:XQPCACHE"
EXTENT CACHE SIZE 64 MAXIMUM BLOCKS IN EXTENT CACHE 989
FILE ID CACHE SIZE 64 BLOCKS IN EXTENT CACHE 0
QUOTA CACHE SIZE 0 MAXIMUM BUFFERS IN FCP CACHE 3534
VOLUME OWNER UIC [SYSTEM] VOL PROT S:RWCD,O:RWCD,G:RWCD,W:RWCD

VOLUME STATUS: ODS-2, SUBJECT TO MOUNT VERIFICATION, FILE HIGH-WATER MARKING,
WRITE-BACK CACHING ENABLED.

$ DISMOUNT DADAR$DKA0:
$ INIT DADAR$DKA0: BACKUP
$ MOUNT/OVER=ID DADAR$DKA0:
%MOUNT-I-MOUNTED, BACKUP MOUNTED ON _DADAR$DKA0:
$ SHOW DEV/FULL DADAR$DKA0:

DISK DADAR$DKA0:, DEVICE TYPE HP 73.4G MAX3073NC, IS ONLINE, ALLOCATED,
DEALLOCATE ON DISMOUNT, MOUNTED, FILE-ORIENTED DEVICE, SHAREABLE, AVAILABLE
TO CLUSTER, ERROR LOGGING IS ENABLED.

ERROR COUNT 0 OPERATIONS COMPLETED 4584474
OWNER PROCESS "_TNA58:" OWNER UIC [SYSTEM]
OWNER PROCESS ID 000010F4 DEV PROT S:RWPL,O:RWPL,G:R,W
REFERENCE COUNT 2 DEFAULT BUFFER SIZE 512
CURRENT PREFERRED CPU ID 0 FASTPATH 1
TOTAL SIZE 68.36GB SECTORS PER TRACK 96
TOTAL CYLINDERS 15558 TRACKS PER CYLINDER 96
LOGICAL VOLUME SIZE 68.36GB EXPANSION SIZE LIMIT 80.71GB

VOLUME LABEL "BACKUP" RELATIVE VOLUME NUMBER 0
CLUSTER SIZE 144 TRANSACTION COUNT 1
FREE SPACE 68.36GB MAXIMUM FILES ALLOWED 494395
EXTEND QUANTITY 5 MOUNT COUNT 1
MOUNT STATUS PROCESS CACHE NAME "_DADAR$DKB200:XQPCACHE"
EXTENT CACHE SIZE 64 MAXIMUM BLOCKS IN EXTENT CACHE 14337316
FILE ID CACHE SIZE 64 BLOCKS IN EXTENT CACHE 0
QUOTA CACHE SIZE 0 MAXIMUM BUFFERS IN FCP CACHE 3534
VOLUME OWNER UIC [SYSTEM] VOL PROT S:RWCD,O:RWCD,G:RWCD,W:RWCD

VOLUME STATUS: ODS-2, SUBJECT TO MOUNT VERIFICATION, FILE HIGH-WATER MARKING,
WRITE-BACK CACHING ENABLED.

$ DISMOUNT DADAR$DKA0:
$ MOUNT/FOR DADAR$DKA0:
%MOUNT-I-MOUNTED, DISK MOUNTED ON _DADAR$DKA0:
$
$ BACKUP/IMAGE/LOG LDA10: DADAR$DKA0:
%BACKUP-S-CREATED, CREATED DADAR$DKA0:[000000]000000.DIR;1
%BACKUP-S-CREATED, CREATED DADAR$DKA0:[000000]BACKUP.SYS;1
%BACKUP-S-CREATED, CREATED DADAR$DKA0:[000000]CONTIN.SYS;1
%BACKUP-S-CREATED, CREATED DADAR$DKA0:[000000]CORIMG.SYS;1
%BACKUP-S-CREATED, CREATED DADAR$DKA0:[000000]SECURITY.SYS;1
%BACKUP-S-CREATED, CREATED DADAR$DKA0:[000000]VOLSET.SYS;1
$
$ DISMOUNT DADAR$DKA0:
$ INIT DADAR$DKA0: BACKUP1
$ MOUNT/OVER=ID DADAR$DKA0:
%MOUNT-I-MOUNTED, BACKUP1 MOUNTED ON _DADAR$DKA0:
$ DISMOUNT LDA10:
$ MOUNT/FOR LDA10:
%MOUNT-I-MOUNTED, BACKUP MOUNTED ON _DADAR$LDA10:
$ BACKUP/LOG/IMAGE DADAR$DKA0: LDA10:
%BACKUP-S-CREATED, CREATED LDA10:[000000]000000.DIR;1
%BACKUP-S-CREATED, CREATED LDA10:[000000]BACKUP.SYS;1
%BACKUP-S-CREATED, CREATED LDA10:[000000]CONTIN.SYS;1
%BACKUP-S-CREATED, CREATED LDA10:[000000]CORIMG.SYS;1
%BACKUP-S-CREATED, CREATED LDA10:[000000]SECURITY.SYS;1
%BACKUP-S-CREATED, CREATED LDA10:[000000]VOLSET.SYS;1
$

Regards,
Ketan