Operating System - OpenVMS
1753358 Members
5178 Online
108792 Solutions
New Discussion юеВ

Re: Cluster size of large disks

 
Antoniov.
Honored Contributor

Re: Cluster size of large disks

Like Hein, I prefer cluster size power of two. Value 51 is unusual, strange.

Antonio Vigliotti
Antonio Maria Vigliotti
Gerry Downey
Frequent Advisor

Re: Cluster size of large disks

Ian, I had a look at the link you provided. From reading the documentation with VMS
7.3-2, I see that I can set the cluster size to what ever I want and then do a
BACKUP/IMAGE/NOINIT to preserve the cluster size. So I definately have to upgrade.

I seem to have you all intrigued as to why the cluster size is important. I'll try to find out why and let you know.
Robert Gezelter
Honored Contributor

Re: Cluster size of large disks

Gerry,

As everybody else has noted, the cluster size is, when all is said and done, likely irrelevant.

As to the genesis of the myth, I would speculate two things:

- the selection of the cluster size at some point may be linked with ancient disk geometry. At some point in the past, someone may have decided that it seemed a good idea to ensure that clusters aligned on disk boundaries (track, cylinder). Today, most people ignore that fact. This was not so in the past. Many other operating systems (e.g., IBM's OS/360 and CDC NOS) did in fact encourage this type of thinking. Provided it did not cause excessive "breakage", it isn't a bad idea. Breakage can be impressive, I have seen 20-30% values at times, a strong argument AGAINST large cluster sizes.

- somewhere along the line, someone made the presumption that cluster sizes related to RMS bucket sizes.

In short, before migrating disks or similar action, track down the source of this myth, and set it right.

If the applications firm does not give a solid explanation, consider calling in an HP or solid third party consultant to take a look at the question. It is not uncommon to find such a thing is an artifact of the testing configuration. A small review and some conference calls can literally save tens of thousands of dollars of budget spent on unneeded system management exercises (Yes, to be honest, I have resolved several of these types of situations in the past, but I digress).

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

Re: Cluster size of large disks

Gerry,

As to a short term solution, I would recommend a good look at the use of LD.

- Bob Gezelter, http://www.rlgsc.com
Uwe Zessin
Honored Contributor

Re: Cluster size of large disks

Today, you cannot really 'align on cylinder boundaries', because modern disks don't have a fixed geometry, inside. The number of sectors is larger on the outer tracks. Try to tell that an OS. And most of the time a disk drive is behind a RAID controller, anyway.
.
Antoniov.
Honored Contributor

Re: Cluster size of large disks

Gerry,
I'm happy you upgrade you os version. I'm also intrigued by this choice; usually system administrators don't love upgrade theyr machine to avoid compatibility trouble. So the reason of keep cluster size to 51 is very very strong!
If you need help for upgrade, post: we are here!

Antonio Vigliotti
Antonio Maria Vigliotti
Willem Grooters
Honored Contributor

Re: Cluster size of large disks

>The application is a third party
>application that uses RMS and I've
>been told that the cluster size must
>be 51 or lower.

There can be good reasons!
What is meant by "RMS" in this case? It may mean "Record Management System" - the VMS meaning - but who knows it has something to do with memory: "Reusable Memory Storage", perhaps? Just a guess. In that case, it can very well be feasable to limit the clustersize on disk, where is is possible to read whole clusters of data directly into memory - bypassing VMS's RMS. Maximum clustersize of 51 means a 25,5K buffer.

Just a question on this: does the application require LOGIO of PHYIO privilege? That would be a signal of this behaviour.

Why you should need to, and not use VMS's own facilities is another matter. Maybe the program ws originally written for Unix?

Anyway: you will need to upgrade. Given the nature of the program, I would test it with a higher version of VMS. It is very well possible that it won't work when it is linked against the system!

Willem
Willem Grooters
OpenVMS Developer & System Manager
Peter Barkas
Regular Advisor

Re: Cluster size of large disks

Mmmm, RMS could mean "Royal Microscopical Society" too.

A somewhat more likely answer is that the application was written in a way that attempted to do, or thought that it was doing, some sort of optimised IO but perhaps had only limited internal storage. If the application is old, a clustersize of 51 might have seemed future-proof at the time.
Robert_Boyd
Respected Contributor

Re: Cluster size of large disks

Bob Gezelter and anyone else familiar with the inner workings of ODS 2/5 on recent versions of VMS:

I'm confused -- comments about the irrelevance of cluster size compared to sector size -- if you choose a cluster size that is not an integer multiple of the sector size, what happens to the pieces that are left over?

My impression from past descriptions of how the drive gets broken up into useable hunks of media leaves me with the impression that randomly picking a cluster size leads to wasted space or inneficient use.

Robert
Master you were right about 1 thing -- the negotiations were SHORT!
Robert Gezelter
Honored Contributor

Re: Cluster size of large disks

Robert,

Cluster size is independent of the numbers of sectors on a track. Clusters follow one another, if a cluster does not fit on the track, it continues into the next track (or cylinder, if the this occurs on the last track in the cylinder).

At first glance, this may seem inefficient, but the reality is that the benefit of multiblock allocations outweighs the negative effects of the occasional cluster that spans a physical boundary.

In many cases, at least in the past, the number of blocks was a composite number (product of two or more numbers), thus it was possible, without wastage, to keep a cluster completely on a track. I have seen more than a few cases where the numbers of sectors per track are constant and a prime number (e.g., a number divisible only by one and itself). In that case, the only cluster factors that would not yield track crossing would be 1 (which would be inefficient to allocate space, creating a high degree of fragmentation) or a cluster size equal to the track size (which would yield a tremendous loss of space due to "breakage", the unused, and unallocatable space at the end of the file).

The main performamnce loss is not from spanning tracks or cylinders (of which only cylinders is truly significant), but the overheads from highly fragmented allocations and multiple file headers.

Of course, all of these effects are harder to observe when there are caches at different levels in the hierarchy obscuring what one is trying to measure.

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