Changing disk Cluster_sizer

[Peter Zeiszler]

I am curious if there is any way to change a disks cluster_size without initializing the disks and moving the data around.

I currently have some large disks that are ODS-2 format and they have large cluster size. Someday I would like to get them converted to ODS-5 and decrease the disks cluster size. If I can do it online or without having to allocate additional disks to move the data around that would be the best.
(hoping that someone knows an undocumented feature)

[John McL · Accepted solution]

Think of what would have to take place ... a new bitmap that corresponds to the cluster allocations would need to be created and built from scratch. If the new cluster was not a multiple or an even fraction of the old size it would require changes to file pointers in INDEXF.SYS (e.g. 16 down to 8 would be simpler than 16 down to 9). No files, not even INDEXF.SYS could be open on the disk at the time when you made the changes because it would be working with the wrong cluster size, but where else would you write the new INDEXF.SYS and BITMAP.SYS files?

VMS is not just about what might be possible but about providing reliable means of doing things. Changing cluster size on the fly is not something that seems likely to be done with a guarantee of being bullet-proof.

[Hein van den Heuvel]

Sorry, no can do.

Conceivable you could construct a tool which would create a fresh BITMAP.SYS (mapping) where each BIT was an exact whole fraction of the current cluster size. Then for every original bit create set/clear the corresponding number of new bits, and flip the file. I don't think such tool exists.

also, Typically large, uncontrolled, cluster sizes have odd, often even prime values, so good luck with that!

A better plan will be the check otu the LD driver and create a virtual disk with small cluster size on top of the big disk!?

hth,
Hein

[Robert Gezelter]

Peter,

With all due respect, I must disagree with Hein. While I do recommend extreme caution, this can be done, and I have done it in the past.

It is a somewhat laborious process, and must be done with extreme care, but the cluster size can be reduced. The restriction is that the new clusters must be a evenly divide the current cluster size (e.g., if the current cluster size is 45, the new cluster size can be 1, 3, 5, or any other factorization of 45; if your cluster factor is presently a prime number, then the only easy reduction is to 1).

- Bob Gezelter, http://www.rlgsc.com

[John Gillings]

Peter,

Unless your cluster sizes are really VERY large, and you're storing large numbers of very small files, is there any real benefit in your proposed decrease?

Consider the distribution of file sizes stored on the volume. There are many tradeoffs here, but don't dwell too much on "wasted space". These days I think it makes more sense to use a larger cluster size and enjoy the performance benefits.

What size are you now, and what size were you thinking of changing to?

[Peter Zeiszler]

Can't convert them today but the current cluster sizes are: 272 and 480. If I can get them to ODS-5 I would just use the default size of 16.

They have mixed file sizes. Some directories are lots of small files. Others are large database files - which don't seem to affect the allocated space as much.

Thanks for the input.

[Mike Kier]

I don't think you need to move to ODS-5 just to get the larger bitmap file size that would allow for smaller cluster sizes. I don't remember the release it came in, but I'm sure at least OpenVMS Alpha 7.3-2 allows ODS-2 files with extended bitmaps. It should be as simple as a Backup/Init/Restore operation. As long as you can plan the downtime, it should be straightforward. You can't do it if you have a VAX in the cluster that mounts the volume, though.

[comarow]

You could shadow up a larger disk, or with a lower cluster size. Or even the same size.

Backup/Image olddisk tempdisk

Then, reinitialize your old disk and restore
to it. Don't forget /noinitialze

Init the new disk with a smaller cluster size
and ods5 if desired.

Then
Backup/image/NOINITIALIZE no drive.

Note that if you can simply replace the disk,
you can shadow to it and be done with it.


Primitive but works.

Have fund

[Ian Miller.]

OpenVMS V7.2 introduced support for large bitmaps and hence smaller disk volume cluster factor.

[Peter Zeiszler]

I have a shadow disk - trying the re-init, backup, move data. Seeing if that will give us more freespace.

Normally I don't init disks - rarely get any new ones. Didn't think of cluster size being a problem since the last 2 disks I did get were ods-5 and they defaulted to 16. I do notice header size is currently extended to 400000 blocks so am going to dictate that size already.

When I did the init and then mounted I did the message:
%BACKUP-I-ODS2COMPAT, output volume $1$DGA8005: structure [ODS-2] is not compatible with OpenVMS versions prior to 7.2

Good thing I don't mount the disk on any older OS.

Thanks guys. Will let you know how this turns out.

[John Gillings]

Peter,

Before doing this, please get a DIRECTORY/SIZE=ALL of the existing disk. Drop the results into Excel and calculate the disk space saving you'll get by changing to different cluster sizes.

Make sure it's really worth your time and the risk of reducing your shadow sets to a single volume - I suspect it won't be.

Also consider the additional time and resources you'll consume running a defragger to make files contiguous, which, with a larger cluster size, could never be fragmented.

[Peter Zeiszler]

I did one disk so far as a test. Saved 77million blocks.

[AEFAEF]

Peter,

You may need to pay careful attention to INIT qualifiers such as /HEADERS, /MAXIMUM_FILES, /CUSTER_SIZE, and any other related ones I may be missing. If MAXIMUM_FILES is too high, the next expansion of INDEXF.SYS will be unexpectedly huge!

See

http://groups.google.com/group/comp.os.vms/msg/62dbb9ac233ea900

for details. Granted, since you saved 77 million blocks, this may not matter for you, depending on your disk size and such.

AEF