Selecting values for disk INIT /CLUSTER_SIZE=

[Jack Trachtman]

We now use our EVAs for most of our disk needs.

I'm wondering what disk /CLUSTER_SIZE= values others are using when you inititialize disks. I believe that for efficient use on EVAs, the cluster sizes should be multiples of 16.

As a somewhat arbitrary starting point:

< 1000 files, CS=256
> 1000 files, CS=64

[Hoff · Accepted solution]

Is there a question here?

With fewer numbers of larger files, larger cluster sizes are better. With larger numbers of smaller files, smaller cluster sizes are better. This in terms of wasted space. On average, one half of the cluster factor times the number of files present on a disk is wasted space.

But with a street price at US$400 for a terabyte disk spindle, cluster-level waste can become somewhat less of an issue.

A cluster factor that is a multiple of 16 is traditionally recommended by OpenVMS Engineering.

Setting the extend size to a reasonable value is a bigger win, in my experience. Caching is a bigger win. Setting the header count right is important, too, as the default count is often, um, suboptimal.

INITIALIZE command tips:
http://10.1.2.7/node/193

Disk sector sizes:
http://10.1.2.7/node/284

[Jan van den Ende]

Jack,

no surprise, I fully agree with Hoff.
>>>
Setting the extend size to a reasonable value is a bigger win,
<<<
reasonable would of course by a multiple of clustersize (compare with default: clustersize 3, or 81 , or such combined with extend size 5. AAARgh!)
>>>
Setting the header count right is important,
<<<
Yeah. If you are expecting mostly smallish files, even the MAX ( ~ 16 M; 2^24 - 2^16 - 1 to be exact) can become limitting on todays drives or RAID volumes.

Perhaps superfluous, I would add not to forget /LIMIT = 1Tb

That said, we _DO_ have one drive with cluster=1.
Used as a "work" disk for an operation that generates, processes, and deletes many (sometimes 10000's, sometimes over 2,000,000 ) of 1-block files. It was setup so before we moved to SAN. Maybe now we might reevaluate that choice, but we just do not think it is worth that trouble.


hth

Proost.

Have one on me.

[Jan van den Ende]

Jack,

from your Forum Profile:


I have assigned points to 480 of 561 responses to my questions.

The oldest dates back to 2004!


Maybe you can find some time to do some assigning?

http://forums1.itrc.hp.com/service/forums/helptips.do?#33

Mind, I do NOT say you necessarily need to give lots of points. It is fully up to _YOU_ to decide how many. If you consider an answer is not deserving any points, you can also assign 0 ( = zero ) points, and then that answer will no longer be counted as unassigned.
Consider, that every poster took at least the trouble of posting for you!

To easily find your streams with unassigned points, click your own name somewhere.
This will bring up your profile.
Near the bottom of that page, under the caption "My Question(s)" you will find "questions or topics with unassigned points " Clicking that will give all, and only, your questions that still have unassigned postings.
If you have closed some of those streams, you must "Reopen" them to "Submit points". (After which you can "Close" again)

Do not forget to explicitly activate "Submit points", or your effort gets lost again!!

Thanks on behalf of your Forum colleagues.

PS. - nothing personal in this. I try to post it to everyone with this kind of assignment ratio in this forum. If you have received a posting like this before - please do not take offence - none is intended!

PPS. - Zero points for this.

Proost.

Have one on me.

jpe

[Robert Gezelter]

Jack,

I would agree with what has been said previously, with two additions and one reservation.

Setting cluster size with an awareness of the caching proclivities of the EVA (e.g., in multiples of 16) is certainly reasonable. Please document that this is the reason in the event that future storage systems change that underlying presumption in some what and produce a performance anomaly.

Setup your disks so that you can transform them to larger disks online without imposing downtime on your user community, as I described in "Migrating OpenVMS Storage Environments without Interruption or Disruption" at the 2007 HP Technology Forum in Las Vegas (the slides are available via http://www.rlgsc.com/hptechnologyforum/2007/1512.html ).

The warning that I will add is while doing this, be aware of "breakage". I have seen classic results of the "billion here, a billion there, sooner or later it is real money". In the case of disk storage, I have seen disks that had over 25% of their space tied up due to the differences between allocated and used space (that was with small cluster factors under 10), with the large numbers, it is potentially a more serious issue).

I hope that the above is helpful.

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