VA lun space allocation

[Steve Lewis]

The horrid thing about the VAs is that we never know where its going to put stuff in reality. All we do know is that all data within a RG is striped over all the disks in the RG.

Can anybody who knows please tell me this:
When you create a LUN, does is pre-allocate a portion of physical RG space to the LUN in the form of a single fat empty block of space striped over the disks,
OR does it merely subtract the size from the total available, allocate a single block from the space map, then allocate further physical blocks as the space gets used up, until the LUN is full?

Knowing this would significantly help me with configuration for performance as I have database 3 instances on 1 VA and I don't want them interleaved.

[Vincent Fleming · Accepted solution]

As I recall, the VA allocates entire stripes at a time.

If you're concerned about where the data is, you can 'dd' to the LUN(s) one at a time to pre-allocate the space on the disks.

However, the VA can "shuffle" the data blocks around - to locate often-accessed blocks closer together. This is to increase your performance by decreasing head movement within the array. The effect of this can interleave the LUNs at a later date.

So, interleaving the LUNs is not necessairly a bad thing.

Good luck,

Vince

[Uwe Zessin]

Steve,
I've checked an old training guide and it says:

* LUN creation reserves space from available clusters

* 'new writes' (space not previously allocated) cause allocation of physical space (cluster)

(Each disk is broken up into 4MB spaces called Physical Extents (PEX). PEXs are broken into 256K segments called a cluster.)

[Steve Lewis]

Thank you both that was quite helpful.
I have a bizarre situation in that somebody has dumped 200Gb of data into my 2nd big database and now when I run a regular process that reads from old tables and creates new ones I suddenly have a hot disk with queues up to 350(!) and wait times >1 second in sar -d. There are no errors in the logs.
The copying of all that data is the only change that has happened. The code is the same, the patches are the same, everything else is unchanged.
Maybe, previously the new tables were closer to the old ones in the same LUN and have been moved way off toward the centre of the disks, causing head flapping.
Maybe the array decided to start moving blocks closer together at the same time the process was running.
Increasing the SCSI max_queue_depth in HP-UX has had not effect because it merely moved the bottleneck to the storage array.
I have about 1.6Tb of usable storage in 20 LUNs of 80Gb, fixed RAID 1/0.

[Nguyen Anh Tien]

VA prodically optimize and balance itself. so all data on VA will be reorganzie at this time.
When you Create new LUN. VA get space from total available. (total available is spave that strip ovar all disks in RG)

[Arend Lensen]

Steve,

Keep in mind that HP recommends to leave the space of 1 or disks per RG unallocated for best performance. Did you configure the Queue Full Treshold (QFT) to the right value?.

Regards,
Arend

[Steve Lewis]

Yes I have left > 1 disks' worth in each RG and Yes the queue full threshold is tuned.

[Steve Lewis]

thanks all