Alignment offset

It is better to use the host file-system offset. In either case, you can not set the off-set once a LUN has been assigned and formatted and contains data. As Ken said in his post, you can create a new LUN, set the offset and then copy the data over to the new LUN.

For Best Practices see the two documents - the flare 26 is specifc for the CX3, the flare 30 is for the CX4, but has updated information that applies to the CX3 also.

EMC CLARiiON Performance and Availability Release 30 Firmware Update Applied Best Practices.pdf

http://powerlink.emc.com/km/live1/en_US/Offering_Technical/White_Paper/h5773-clariion-best-practices-performance-availability-wp.pdf

EMC CLARiiON Storage System Fundamentals for Performance and Availability

http://powerlink.emc.com/km/live1/en_US/Offering_Technical/White_Paper/H1049_emc_clariion_fibre_channel_storage_fundamentals_ldv.pdf

EMC CLARiiON Best Practices for Fibre Channel Storage: FLARE Release 26 Firmware Update - Best Practices Planning

http://powerlink.emc.com/km/live1/en_US/Offering_Technical/White_Paper/H2358_clariion_best_prac_fibre_chnl_wp_ldv.pdf

glen

I do see 100% utilization at times. If nothing else I would like to follow best practice. Can I create a LUN and set the alignment value on the clariion then migrate the host LUN to the new offset LUN?

On W2003 servers,  you need to use diskpart when you present a new lun to a host.  the command is "create partition primary align=64".

If you already have data on those lun's, do not do this as it is desrtuctive and you will lose all data.   You only way to fix this is to present new lun's to the host, set the alignment, and then migrate the data over to the new lun.

Are you having performance issues?

Is it better to make the alignment offset on the host or on the Clariion?

Tocs wrote: I do see 100% utilization at times. If nothing else I would like to follow best practice. Can I create a LUN and set the alignment value on the clariion then migrate the host LUN to the new offset LUN?

Yes  but the data would need to be migrated with some type of host based tool.  You would not be able to let say, create a new lun present it to a host, set the alignment, and then use the array based Lun migration to move data to it.   That would only copy the source lun to the target lun and since it is by blocks, it would copy over the same incorrect alignment..

And like Glen stated, always use the host to set the alignment.  I myself have never set or seen any one set the alignment on the Clariion.  you can do it, but best practice is to use the host.

The folks here have never done it. I will make sure I do going forward. Thank you much Gents.

So as best practice Anytime I assign a LUN to a W2003 box I should always use diskpart to set the alignment?

Yes.  anytime you assign a new lun to a host, set the alignment.  Do it for w2003.  W2008 does it for you so you dont have to worry about it.

> Yes.

Err.. And suppose his I/O is <4KB? Not all I/O workloads require alignment.  Workloads of predominantly 4 KB I/Os will see only a small advantage from alignment.  Note that 4KB is a common file system I/O block size. 

it's not a 63 bit offset, it's sectors !

But what you need to do on Windows is create the first partition on each LUN using the diskpart tool and create the LUN using a 64 sector alignment.Just as mentioned by kenn2347.

Simply always do it. This way you dno't need to think about whether or not to do it. And even on 4kB blocks it has no disadvantages, so why not do it always ?

I've however seen performance improvements of >25% with larger blocks (32kB if I remember well)

All luns presented to a windows host requires the alignment regardless of the raid type.

You cannot do it the way you are asking with the clariion migrate feature since it copies the lun block by block.  So it would then copy the miss alignment to the new lun and you would be in the same situation.

The only way to correct this is to present a new lun, align it, and then migrate the data with a host based software.

Also, i have heard that some people set the alignment on w2003 to 1024 instead of the 64 to go with W2008 incase they ever were going to move those lun's to a W2008 server.  Never done it myself but i have read it on these forums a few times.

I was thinking of a way to fix my current issue without doing a disk copy as suggested,,, Currently I have 3 DB servers with raid5 lun's. Could I use the clariion migrate feature to migrate to a raid1 to fix a misalignment problem? It my understanding that raid 1 does not require a offset, is that true?

ALL IBM compatible computers have the Master Boot Record of 63 sectors and therefore a misalignment problem. ALL ! It has nothing to do with any RAID level, since it has to do with sectors per track and since the MBR has 63 sectors and a track is 64 sectors per track, you're left with a 1 sector misalignment. What happens when you read the block this 1 sector is in ? It starts with this 1st sector and the rest of the block has to be read from the next track, so the disk heads need to move, causing an extra 3-4ms delay for this one block. But since the first block on the 2nd track now has 1 sector less, this track has a single sector left at the end and so the story starts over again. So per track you have 1 block that suffers severely from this misalignment. If you track has 64 sectors and 4kB blocks, you'll have 64/4=16 blocks per track from which 1 is very slow. If you have 32kB blocks on a 64kB track, every 2nd block suffers !!!

If you align you partition to start exactly at the beginning of a track, you'll never have to move to the next track to read any block (unless you're formatting with 128kB blocks, but you can imagine that you would only want 1 drive head change instead of 2 per block, so even here the alignment will be beneficial for performance.

You can't get rid of misalignment by mirroring or cloning a LUN from RAID5 to RAID10 since it's not RAID level dependent.

If you create a LUN migration LUN with an offset, the number of blocks differs from the original and I'm not entirely sure you can clone from small to slightly bigger.....