Stripe Crossings

It could be normal. I would suggest that you look at the "EMC CLARiiON Best Practice for Fibre Channel Storage - CLARiiON Release xx Firmware Update" - do a search on PowerLink - look in the section called File System Alignment.

Stripe crossings happen when you write a chunk of data that spans more than one stripe. In a 4+1 Raid 5, you will normally have 4 stripes elements of 64KB each for each disk and the stripe will be 4 * 64K = 256KB. If you write a 1MB IO, you'll see 4 stripe crossings.

regards,

glen kelley

Glen,

so how do you determine which stripe crossings are normal and which ones are not ? Is it based on the IO size ? For example if you have a mis-aligned file system, can you tell from LUN stats / Navi Analyzer that that LUNs has crossing that are due to mis-alignment or due to IO size ?

Thanks

I can imagine that having an average IO size and the number of stripe crossings and knowing how a Raid Group is made you can determine roughly whether or not it's due to misalignment. The avg IO size tells you how many IO's there can be in a full stripe and if somehow the expected number of stripe crossings is a bit larger than expected, it's caused by misalignment.

It's tough matter.... Perhaps contacting a performance guru at EMC will be the best idea to get a convincing answer.

RRR,

That¿s correct. Stripe crossings are normal events where large I/O is involved (larger then stripe size). In environments that use smaller I/O sizes it could be a caused by misalignment¿

If crossings in general are a problem then alignment is the way to fix. But instead of setting the starting offset to the stripe element size (64) why not set the starting offset equal to the LUN stripe size i.e. align by 256 on a R5 4+1¿

Thanks & regards
Carl

I was trying to get the basics right, but indeed: you could align by a full stripe as well.
In fact aligning on a full stripe does not take away the extra delay caused by head movement, because aligning on a single track already took care of that, but aligning on a stripe will do some cache improvement, because only 1 stripe has to be written and not 2, therefore not 2 stripes have to be in cache, but only 1. In a heavily loaded Clariion with not much cache to play with, aligning on a full stripe could win something on the cache perspective.

That's a really hard question to answer. Normally we do not use stripe crossing when looking at performance issues. We look at the host alignment first (from the host grab) and if it's a Windows server and it's not aligned, then we may look at the alignment as part of a performance issue. We've seen that some Windows applications are more sensitive to this than others - Exchange is one that seems to benefit.

I know that's not a complete answer, but I know that when Performance Engineering looks at these types of problems, they do look at stripe crossings (but not very often).

Maybe a better way to look at this is to use "Write Throughput (IO/sec)" and "Full Stripe Writes/s" in Analyzer - this way you can see how your writes are working on the array - a big different indicates that the writes are probably small and not a full stripe.

glen

I've even heard from 1 EMC PS engineer that he saw a 50% improvement on some MS SQL server ! 50% !!!

A word of warning with aligning by stripe size¿ Using HYBRID MetaLUNs (i.e. initially striped and then concatenated using the SAME RGs to expand size) will break the stripe alignment! However the same isn¿t true is using disk alignment¿

Not a big problem if you expand by striping but I guess could be one reason why stripe alignment isn¿t pushed as the preferred choice¿

Yup ! Listen to Calle !!
If you even suspect a lun is going to grow, don't align on a full stripe, but keep it to 1 single disk (track). If you know for sure that the lun is not going to grow, align it to a full stripe.