Operating System - OpenVMS
1748019 Members
4518 Online
108757 Solutions
New Discussion юеВ

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

 
SOLVED
Go to solution
BrianT_1
Regular Advisor

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

GF> In this old BACKUP code there are only
GF> two locations where this error is
GF> issued. In both cases the total block
GF> count is involved in the calculation.
GF> So I would first check the total
GF> blocks count the way VMS sees it.

And I've posted that info a couple of times.
Hein van den Heuvel
Honored Contributor

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

Brian, ok, allright,... you DO have a lot of file on that drive! Yikes.

My suggestion was based on a remark in an internal publication "VMSnotes 5776" which read: "Essentially, if a disk is initialized with the maximum allowable values for /HEADERS and /MAXIMUM_FILES, and is then used as the target of a disk-to-disk image backup, the backup will fail almost immediately with the %BACKUP-F-CLUSTER error. If the same target disk is reinitialize using (maximum-1) as the value for /HEADERS and /MAXIMUM_FILES, the backup will proceed and complete normally."

That was on 7.3, but on re-read is was Alpha and suggested not reproducable on VAX 7.2 or 7.3.
I just tried a SMALL reproducer (a few thousand block MD device) on VAX 7.1... no failure.

I also tried a full reproducer under Alpha 8.3... no failure. See log below.

So I do NOT think that a slightly reduced /HEAD, to be under /MAX and more close to the needed size will help after all. (note: the backup restore phase nicely grows indexf as needed).

An other old note suggest the following
"Backup reports the error BACKUP$_CLUSTER under two circumstances:-

1. If the volume_size / cluster_size is greater than 1044480 or
- if the volume_size / cluster_size is less than 50

2. If the maximum_files_allowed is greater than volume_size / cluster_size + 1"

But that was before 7.2, and neither apply here it seems.

Good luck!
Hein

$ ld create $1$dga200:[temp]tillman.dsk/size=53294505
$ ld connec $1$dga200:[temp]tillman.dsk lda2:
$ init /max=1500000 /head=3000000/clust=8 lda2: test
$ moun lda2: test
%MOUNT-I-MOUNTED, TEST mounted on _$10$LDA2: (HEINA)
$ shwo dev /full lda2
:
Total blocks 53294505 Logical Volume Size 53294505 Expansion Size Limit 53444608
Free blocks 51792456
Maximum files allowed 1500000
:

$ dir/size=all lda2:[000000]*.*
:
BITMAP.SYS;1 1628/1632
:
INDEXF.SYS;1 409/1500400
:
Total of 10 files, 2047/1502056 blocks.
$
$ cre/dir lda2:[test]
$ copy sys$manager:*.dat lda2:[test]
$ dir /grand lda2:[*...]

Grand total of 1 directory, 9 files.
$ dir /grand/size=all lda2:[*...]

Grand total of 1 directory, 9 files, 175/216 blocks.
$ back/image lda2: $1$dga200:[temp]tillman.bck/save
$ dism lda2:
$ init /max=1500000 /head=3000000/clust=8 lda2: test2
$ mount/for lda2:
%MOUNT-I-MOUNTED, TEST2 mounted on _$10$LDA2: (HEINA)

$ back/noinit/image $1$DGA200:[temp]tillman.bck/save lda2:
%BACKUP-I-LOGNOTPRES, logical volume size of volume LDA2: not preserved
%BACKUP-I-LIMITNOTPRES, expansion size limit of volume LDA2: not preserved
%BACKUP-I-ODS2COMPAT, output volume LDA2: structure [ODS-2] is not compatible wi
th OpenVMS versions prior to 7.2

$ back/image $1$DGA200:[temp]tillman.bck/save lda2:
%BACKUP-I-ODS2COMPAT, output volume LDA2: structure [ODS-2] is not compatible wi
th OpenVMS versions prior to 7.2
$

GuentherF
Trusted Contributor

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

Brian,

you didn't mention how you got the total blocks count. I would like to see the output from SHOW DEV/FULL while the disk is mounted foreign (to be sure VMS has it PackAcked).

How do the 9GB drives make up a RAID set with 53294505 blocks?

/Guenther
GuentherF
Trusted Contributor

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

Ok, found it: RAID-5 with 3+1 members.

Using the older BITMAP.SYS size limitation of 255 blocks the maximum disk size for a cluster factor of 8 would have been 255*4096*8 = 8355840 blocks.

A regular INIT gave a cluster factor of 51 which would be 255*4096*51 = 53268480. Calculated based on the older BITMAPS.SYS limit. Looks like BACKUP is shooting for a 255 block BITMAP.SYS limit.

Ah, according to BACKUP V7.3 code it uses a max BITMAP.SYS size of 255 blocks for an ODS-2 volume and 65535 for ODS-5. Which would explain the error message.

It all doesn't make sense, yet. The save set was recorded for an ODS-2 disk WITH A CLUSTER FACTOR OF 8!???

But the INIT/CLUSTER=8 worked on the VAX. What is the disk structure level after the INIT?

What's the link date of SYS$SHARE:INIT$SHR.EXE and BACKUPSHR.EXE?

/Guenther
GuentherF
Trusted Contributor

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

Haven't looked into VAX code for eons.

Here's the story: INIT on VAX/VMS V7.3 allows for a max BITMAP.SYS size of 65535 blocks even for ODS-2 volumes (online help INIT/CLUSTER says something like this at the end). That's why the /CLUSTER=8 worked.

BACKUP on the other hand doesn't do that. If the output volume is ODS-2 it strictly uses a BITMAP.SYS limit of 255 blocks. So this image restore can never work with the original V7.3 BACKUPSHR.EXE (link date 16-MAR-2001).

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

So one option is to pre-initialize the disk volume and do a non-image restore...and get over it.

/Guenther
Robert Gezelter
Honored Contributor

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

Brian,

Please supply the precise error message that users are seeing (e.g., "Forced Error").

Offhand (I just awakened), I do not see a way that an error in BACKUP can produce a hard IO error in accessing the resulting files.

Offhand, a "forced error" on a RAID-5 volume set would seem to imply that either the underlying RAID set members are having problems or that there is a hardware problem somewhere else in the datapath.

- Bob Gezelter, http://www.rlgsc.com
Jon Pinkley
Honored Contributor

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

Interestingly, Art Wiens reported this same error on Jun 17, 2007 in the following thread:

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1140240

This is a reasonably serious shortcoming of BACKUP, or in Brian's words "With or without tweaks, BACKUP in OpenVMS VAX V7.3 is clearly broken." Besides being much slower when there are a large number of files, and even worse if there are large directories, there are some things that a non-image restore will not do correctly. The primary shortcoming of non-image BACKUP is the inability to restore a bootable system disk, or any disk with alias entries. Other issues are that date stamps of directory files are not restored. Also, you must be much more vigilant to get file ownership correct.

This is not the only time that BACKUP has lagged ODS enhancements. Support for volume expansion was added in Alpha VMS 7.3-2, but backup didn't fully support this until VMS 8.3. Specifically, when doing a backup/image/noinit saveset disk:, the /SIZE of the disk is always maximized prior to VMS 8.3.

This restriction could even potentially affect the ability to restore image backups of system disks with small cluster sizes. It's a good reason to never have a VAX system disk with an extended bitmap.

I would argue that BACKUP enhancements should be in lock step with enhancements to the ODS structures, or possibly come before them.

Jon
it depends
BrianT_1
Regular Advisor

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

GF> you didn't mention how you got the
GF> total blocks count.

$ show device/full disk:

GF> I would like to see the output from
GF> SHOW DEV/FULL while the disk is
GF> mounted foreign (to be sure VMS has it
GF> PackAcked).

Can't do that just now. People have to use the disk.

GF> Ah, according to BACKUP V7.3 code it
GF> uses a max BITMAP.SYS size of 255
GF> blocks for an ODS-2 volume and 65535
GF> for ODS-5. Which would explain the
GF> error message.

Sure would. BITMAP.SYS on these volumes is 1632

GF> It all doesn't make sense, yet. The
GF> save set was recorded for an ODS-2 disk
GF> WITH A CLUSTER FACTOR OF 8!???

You bet.

GF> But the INIT/CLUSTER=8 worked on the
GF> VAX. What is the disk structure level
GF> after the INIT?

ODS-2, naturally. "Volume Status: ODS-2,
subject to mount verification, write-back caching enabled."

GF> What's the link date of
GF> SYS$SHARE:INIT$SHR.EXE and
GF> BACKUPSHR.EXE?

16-MAR-2001 02:53:20.87 and 16-MAR-2001 03:03:16.95, respectively.

GF> So one option is to pre-initialize the
GF> disk volume and do a non-image
GF> restore...and get over it.

That's what I did and all would have been well, but now I'm battling the FORCEDERROR problems I mentioned. I'm trying to decide if they are in the saveset or developed after the restore. I can deal with the latter, perhaps, by replacing the disk drives and restoring those files that report the error.

RG> Please supply the precise error
RG> message that users are seeing
RG> (e.g., "Forced Error").

Here's one:

%COPY-E-READERR, error reading $1$DU103:[AB139SW.EDPU_OFP.WORK.COVIAK]ASM_OBJ.XL
B;90
-RMS-F-RER, file read error
-SYSTEM-F-FORCEDERROR, forced error flagged in last sector read

I found that for many of these files only COPY produces the error. DIFFERENCE, TYPE, and CONVERT do not. I used TYPE/OUT on a text file to make a copy of it and used DIFFERENCE to compare the result and everything was fine. EDIT also works and the data seems intact. We have a program, though, that counts lines of code for Ada programs and that program simply hangs trying to process one of these files. I think you're correct about the underlying hardware.

JP> I would argue that BACKUP enhancements
JP> should be in lock step with
JP> enhancements to the ODS structures, or
JP> possibly come before them.

I'd agree, but we all know that OpenVMS VAX is the poor stepchild and even before it was end-of-life Compaq/HP withdrew life support. I doubt they'd entertain fixing bugs, even ones so blatant and this BACKUP one.
Robert Brooks_1
Honored Contributor

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

JP> I would argue that BACKUP enhancements
JP> should be in lock step with
JP> enhancements to the ODS structures, or
JP> possibly come before them.

I'd agree, but we all know that OpenVMS VAX is the poor stepchild and even before it was end-of-life Compaq/HP withdrew life support. I doubt they'd entertain fixing bugs, even ones so blatant and this BACKUP one.

--

That's not true; I still see periodic VAX fixes checked into the source pool. Admittedly, not too many, but it's not correct to state that it's been completely abandoned.

We have been known to generate VAX patch kits in the recent past as well.

Assuming you have a current support contract, please log a call and report back either here or on EISNER with what happens.

I'll see if I can generate some interest within VMS Engineering to take a look at this.

-- Rob
BrianT_1
Regular Advisor

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

RB> That's not true; I still see periodic
RB> VAX fixes checked into the source pool.
RB> Admittedly, not too many, but it's not
RB> correct to state that it's been
RB> completely abandoned.

Those changes don't seem to be making it out to the public.

RB> We have been known to generate VAX
RB> patch kits in the recent past as well.

There have been two patches this year, one so that MONITOR would work in a mixed architecture cluster and one to fix a Screen Management security hole. The most recent one before that was one in 2006, then one in 2005. Not a very active effort.

RB> Assuming you have a current support
RB> contract, please log a call and report
RB> back either here or on EISNER with what
RB> happens.

I don't have a support contract. What would the thousands of dollars over the last ten years have gotten me? Almost nothing. Hardly a wise use of company money. At any rate, I sent a message via HP's OpenVMS support web site five days ago and received nothing but a robo-reply, so can't imagine any better response by phone, especially since I don't have a contract.

RB> I'll see if I can generate some
RB> interest within VMS Engineering to take
RB> a look at this.

I'd really appreciate this. I'm not making demands, but it would be great if the some resolution came to fruition.