| Title: | VAX and Alpha VMS |
| Notice: | This is a new VMSnotes, please read note 2.1 |
| Moderator: | VAXAXP::BERNARDO |
| Created: | Wed Jan 22 1997 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 703 |
| Total number of notes: | 3722 |
Hi, One of my customer would like to change the cluster size of a RZ28 disk by using the method of backup all the file to a tape, then init the disk with the new cluster size following by backup/noinit to restore the original file. But it does not success, following are the message and steps: System: OpenVMS V6.2-1H3 running on ALPHA 4100 1) mount/over=id $2$dua901: ! rz28 cluster size =128 2) backup/image $2$dua901: dsa26:d901.sav/sav/by_own=original 3) dismount $2$dua901: 4) init $2$dua901: area_16/cluster=256 5) mount/for $2$dua901: 6) backup/image/noinit dsa16:d901.sav/sav $2$dua901:/by_original %BACKUP-I-EXITINDEXF, INDEXF.SYS on device $2$dua901: has been extended to accommodate restore files. %BACKUP-F-Cluster, Unsuitable cluster factor for $2$dua901: Why? 256 is less than 1/100 of the disk size, why it still prompt us the message? Is there anyone knows why? Thanks for your help in advance. Kenneth Leung
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 616.1 | What Problem(s) Are Being Solved? | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Tue May 20 1997 10:34 | 21 |
Most sites have no need to alter the disk cluster factor, and setting
it to 256 is very unusual -- what problem(s) are being solved here?
I suspect the problem you are encountering involves the preservation
of the FIDs -- when the restoration is attempted, one or more FIDs
now point past the end of the disk's index file, and the use of the
BACKUP/IMAGE/NOINIT causes the restoration to (correctly) fail.
If the customer wants a larger cluster factor, consider fixing the
applications to use larger extend sizes, or by setting the SYSGEN
parameter RMS_EXTEND_SIZE parameter to, say, 81, or by setting the
indivudual process extend sizes large.
If the customer insists on a disk cluster factor this large, use
COPY or (/NOIMAGE) disk-to-disk BACKUP to relocate the contents of
the disk onto the newer large-cluster-factor disk. This will
assign new FIDs, which will be assigned from the specified new
index file. (But I'd avoid this whole change -- this change is
probably entirely unnecessary.)
| |||||
| 616.2 | BACKUP-F-Cluster signalled in two places | OSEC::DENNISON | Tue May 20 1997 11:49 | 12 | |
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
Might the problem be with number 2?
Ed. Dennison
| |||||
| 616.3 | AUSS::GARSON | DECcharity Program Office | Tue May 20 1997 20:05 | 30 | |
re .*
An RZ28 with a cluster size of 256 will have a limit on the number of
files of around 15000.
As .1 and .2 together imply, the customer in requesting FID
preservation (via an IMAGE backup) and an effective lower maximum
number of files (by increasing the cluster size) could be asking the
file system to deal with a situation where the number of headers
exceeds the maximum number of files. While this is not a logically
impossible situation I can imagine that the file system design and/or
implementation doesn't handle it.
Even 128 seems like a large cluster size. Can the customer supply a
histogram of file sizes or some other reason for wanting to have a
cluster size of 128 let alone 256?
If the request can be justified then the customer will need to ensure
that the number of files on the disk is less than around 15000. If not
then you simply can't do it. You would need a bigger disk or another
disk. If the number of files is low enough then the procedure in .1
will get what the customer wants although I would recommend including
both /HEADERS and /MAXIMUM_FILES on the INIT command and keeping some
documentation around to explain all the considerations that led to the
disk's init parameters e.g. write a command procedure.
re .2
I would think that volume_size / cluster_size + 1 is meant to be
volume_size / (cluster_size + 1).
| |||||