RE: "I run benchmarks and not only did I not see any improvement, I saw decrease vs what we had before."  No doubt, I suggest you read about metas - and also metas relating to sequential performance - in the Best Practices Guide. You have implemented a worst practice in striping a meta across multiple LUNs from the same RAIDgroup (vertical striping of the meta). That hurts performance by sending the heads all across the disk in what should be a sequential access.  And as you noted, a meta is addressed by only 1 SP so that's why your current owner for meta 100 is all SPA despite you building the meta of SPA and SPB LUNs.  Furthermore, you are trying to maximize sequential thorughput but you subdivided your LUNs even more (compared to initial design)! Which means lots of seeks for the disks as they go between all the LUN partitions. Not good.  So, here is what you need to do (all of which you will realize once you have read the BPG)  1) Read BPG 2) Rebuild using 2 LUN per RAIDgroup 3) Stripe at host, or if you must meta using 1 meta per SP, and one LUN from each RG in each meta. So, you end up with 2 metas, one for SPA, one for SPB, each meta striped across all RAIDgroups. Follow same approach if striping on host.  then you'll hit both back end buses, use all drives, use both SPs etc. Still hitting the drives with 2 streams (one form each meta), but still should be pretty good perf. If not good enough, try 1 LUN per disk group and assign one LUN to each SP as you suggest in point 3 below.   FWIW some answers: 1. Is my understanding right that all LUNs in a metaLUN must be owned by the same SP? (in which case an effort to assign different SP's within a metaLUN like shown above was a waste of time). Correct  2. Is my understanding right that since we optimize for sequential i/o and since we can't assign LUNs to different SP's in the same metaLUN there is no benefit to creating metaLUNs striping across raid groups, like they were created above? Incorrect. Simply make 2 metas: one for SPA, one for SPB striped at most from 1 LUN each from each RG as described above  2a. Let's say even if there was any benefit to metaLUNs and striping across raid groups, what could possibly be the benefit of creating and using 4 LUNs for each metaLUN instead of 2 (one in each RG)? None in fact, you made things worse as explained above  3. It looks to me that the best we can do to optimize sequential throughput on the host is to delete all 8 LUNs and crease one LUN in each RG, and then assign them to different SP's. I think this is exactly what was suggested.Yes  I do not want to do any striping in Windows. For a moment I thought metaLUN will be a substitute but now I realized I was wrong. It can be but only under the restriction that a meta can bring only 1 SP into the equation.   There is also a factor here that our application is using mostly block sizes 64-256KB, so having more disks (larger stripe 768KB ) is not going to benefit us. Right? Instead it's best to split the disks and have stripe 384KB and have sequential i/o going at each of raid groups independently. Any feedback on my thoughts? Larger stripe on host can help if the filesystem bundles up multiple IOs into a single request. Meta stripe of ~ 1 MB is fine, see note in BPG about stripe multiplier.  4. Trespassing. This may be related to our config or maybe not, but it looks like on our Windows 2008 host all SPB LUNs want to trespass to SPA, limiting us to 360MB/sec. The same trespassing occurs on another Windows host that is connected to the same array. Any gotchas here? Any specific Powerpath settings to set to make sure trespass doesn't happen or if it happens it is reversed automatically? I think we have all proper licenses and all recent firmware and so on. There are two HBAs and each shows two paths online. Maybe there is some doco that specifically addresses Windows trespassing problems? Not sure what is happening here. IF the Primary owner of the LUN (or meta) is listed as SPB in the Navi properties page for that LUN then Powerpath will move that LUN to SPB.
I have a simple question about  Clariion CX3-20F maximum bandwidth performance.  I was trying to estimate what  bandwidth was available to a newly connected host (connected to Clariion  CX3-20F via 2 hba's) and I got around 250-360MB/sec sustained  sequential read (i/o block 64-2048KB). This is based on 14 new  15K disks configured as  2x Raid5 6+1. I expected to get a lot more  (each disk can do up to 160MB/sec sustained sequential read from the  media, so theoretical max is 12 x 160MB/sec).  So I digged into some specs and  I see that the frame has only one back end bus. I see in the  documentation the following (best practices doco): "then these  five drives can exceed the bandwidth of the back-end bus which  is about 360MB/sec".  Since we have a single back-end bus, I make a  conclusion that Clariion CX3-20F supports maximum bandwidth of ~  360MB/sec, to be shared across all hosts connected to it.  So if one host uses 180MB/sec, then all others will get a maximum of  180MB/sec etc.  Am  I reading this right?  If the above sounds about right, what Clariion  model would be the next closest performance level from CX3-20F (say  something with 2 back-end buses)?  Thanks in advance for any insight.
Clariion CX3-20F maximum bandwidth - simple question