System Disk Cluster Size of 16

[Robert Atkinson]

I've noticed that a fresh install of VMS on Itanium set the system disk cluster size to the default of 16. I don't recall the install asking me for a value.

In your opinions, will there be any real performance deficit with this kind of low value?

The disk is 72GB in total, and runs off an EVA8000.

Cheers, Rob.

[Jon Pinkley · Accepted solution]

Rob,

I wouldn't be worried about it. If you have moved volatile files off the system disk, then cluster size is almost irrelevant.

Disk cluster size has limited affect on performance. If you have many log files open on your system disk, your disk will get fragmented more quickly than if you had a larger cluster factor, but other than that it won't hurt. The effect of fragmentation is window turns and split I/O. Window turns are needed when the there isn't a valid VBN to LNB mapping for the requested VBN. This is analogous to a page fault for an unmapped virtual page of memory. You can minimize window turns by mounting disks with /window=80 if you have sufficient memory to dedicate. This is a bit like increasing your working set. A split I/O is the result of needing to break an I/O request into multiple I/O requests because the request spanned retrieval pointers.

If you don't see a lot of window turns or split I/O operations, then fragmentation is not causing a performance problem. In other words, a highly fragmented file that is never used won't cause a direct problem. It could cause indirect problems because it could be fragmenting the free space.

What value did you want to use, and what were the reasons for that choice?

Jon

[John Gillings]

Rob,

All increased cluster size really buys you is reduced fragmentation.

On a fresh install, especially one to a disk of that size, I'd expect to see pretty much all files contiguous, regardless of cluster size.

As long as you stick to the right multiples for EVA (can't remember if it's 4, 8 or 16, but regardless, you're there), I can't think of any bottlenecks you're likely to encounter as a result of cluster size.

[Steve Reece_3]

Hi Rob,

The VMS installation doesn't ask about cluster size or anything else on how the disk is to be initialized, other than whether it should be ODS2 or ODS5.
With the average system disk, log files are written to rather than read on a frequent basis. Unless your UAF is huge or you're clustering with XFC then this will probably be held in memory on most Integrity servers, as will the rightslist.

The only thing I can think of performance hits on would be the queue database but, then again, if you're hitting the batch queues hard enough for the system disk parameters to matter on an EVA8000 then you probably need to find a better way of running the jobs than in batch.

Steve

[p.balamurugan]

Hi,

If you use default cluster size for small file also it will allocate more space(EX.If you are cluster size is 32 KB and you create 1 KB file it will allocate 32 KB space).It is better to create with small cluster size. More space are not wasted and no performance will be affected.

Regards
Balamurugan

[Colin Butcher]

16 blocks is 8KB, which is the memory page size for current IA64 boxes (and the memory page size for Alpha). It's also the memory page size for EVA cache.

So, 16 (and multiples thereof) is a 'good number' for the IO subsystem if you're using EVAs with IA64 or Alpha. As a side note - if you're using HBVS then it's worth changing the number of blocks the shadow copy process moves to be the nearest multiple of 16 - which is 224.

I generally set the cluster factor and the extend quantity to multiples of 16. The choices depend on what the volume is being used for - lots of small files being created / extended are generally worth smaller numbers, otherwise you can waste a lot of disc space. Look at the file system stats to gain a good idea of what's actually happening.

Sometimes it's worth parking things like log files on a separate volume, such as a LD container that gets used and then archived and replaced by a new one every week or whatever. Basically separate out the different kinds of data you're writing to disc and think about the best way to deal with it.

It's also worth bearing the 'multiple of 16' in mind for RMS too as doing IO to / from EVA in 8kB chunks is best for the EVA cache and also the host system XFC and applications.

Seems to work for me, but as usual YMMV!

Cheers, Colin (http://www.xdelta.co.uk).

[Robert Atkinson]

Cheers for all the answers guys.

[Colin Butcher]

This is a correction to a statement above (with thanks to Jon Pinkey for getting in touch and querying it):

As a side note - if you're using HBVS then it's worth changing the number of blocks the shadow copy process moves to be the nearest multiple of 16 - which is 112 (7 X 16). You can set this explicitly by defining the SHAD$COPY_BUFFER_SIZE logical name early during the boot sequence.

Cheers, Colin.