Alignment offset

in this time of TB's aligning on 1024 sectors doesn't cost you anything

Just wanted to point out an article that when I first started at EMC did a very good job of explaining the situation for me, and it is one I share with clients who ask.  Figured I'd share it here also for those that haven't already seen it.

http://clariionblogs.blogspot.com/2008/02/disk-alignment.html

As for setting to 1024KB (sector 2048), we have a Primus which advertises our updated stance; however, we do acknowledge that 64KB is fine also.

emc104675: "How to align partitions or volumes in Windows 2003 using the new diskpart align parameter"

[...]

diskpart> create partition primary align=1024

Previously EMC has stated to align partitions at sector 128 by using align=64 .  Using align=64  is perfectly fine for EMC Storage and for EMC standards, but to remain in-line with Microsoft standards please use align=1024.  Please see Microsoft technet article 929491, which details that you should align at sector 2048 using align=1024.

[...]

However, for Linux (x86), best practice is to align to sector 128 using fdisk.

The whole issue is the extra drive head movement during an I/O to/from 1 block. If you can eliminate that the misalignment is gone. You can argue whether or not a stripe misalignment is bad for performance and the only disadvantage I can think of is that with a misaligned stripe a full stripe write might cross a back end stripe.... not sure if that's correct, since the CX performans the FSW, not the host, but if a stripe is 512kB and the host writes 512kB on a 64 sector aligned partition, only the first disk is affected and looses 64 sectors, so the actual data will go to disk2, 3, 4, 5, 6, 7, 8 and then back to 1 for example, starting at the 2nd stripe. If you take out the whole stripe, so align the 1st partition on 8 x 64kB = 512kB = 1024 sectors, each stripe actually begins at the 1st disk and a full stripe write doesn't cross a stripe boundary.

Does this make sence ?

It all make sence.

Again my thought is use the clariion to migrate the data to a raid 1 (no striping) device, then create a raid5 device with an offset and migrate the data to the raid 5 device. My goal, if possible is to fix the issue without disrupting the application/users. Will this work

Thank you all, its been a good discussion.

63 is sector .. not offset.. That reminds me something of RRR again..I can see his notes are awesome.

Now i have another question.. what is special with Linux, why to  set to 128 sector?

never mind. I misunderstood the linux part.. by sector 128 it is align=64 which is normal.

Nominate me

I did nominate for Dynamox and later some from EMC took that further ...

32KB block versus 64KB track , every second block suffers.. What would happen if the read size are higher, for example more than 64KB or 100KB read size? Also what would be the impact if the write size is higher too?

If you align your partition in such a way that a block is placed on 1 track instead of 2, performance is at it's best. If your track is 64kB and your blocks are 128kB, align your partition to 128kB, this way the start of the partition is at the beginning of the first disk, right in the beginning of a track. It still needs to read from 2 disks, but it's in 1 stripe instead of 2.

But the impact of having a partition only aligned to a single track instead of a whole stripe is minimal. Alignment to a track is the largest and most important step. If you have a RAID5 (4+1) raid group, align it to 4 x 64 = 256. Aligning to 64 is 99% of the performance, the rest is so little, that most of the times you can disregard this, but if you want to get every little bit of performance out of your array, align it to a stripe.