concat/stripe meta in virtual privisioning

Symmetrix Performance Engineering always recommends striped metas on VP if you don't ever need to expand them, or if expansion is more important than performance.  Striped will have beter maximum performance capabilities.

Multiple levels of striping isn't really an issue with VP, as the pool is already randomized.

I am under the impression that the data is layed down in a round robin fashin across the TDAT's, not randomly.  When we create luns in a pool we pre-allocate the entire lun; perhaps this is the difference.  If the recommendation is to always stripe luns when will the virtual provisioning guide be changed?  As the original poster noted the guide states only to stripe when approved by a speed guru.

Yes, round robin, which tends to spread every device "randomly" over the pool.  Pre-allocation will still use a round robin.

As far as I know the guide says if you care about performance use striped, or if expansion is not needed or is not as important as performance.

Just pulled this from the Guide...

In most cases, EMC recommends using concatenated rather than striped metadevices with Virtual Provisioning. However, there may be certain situations where better performance may be achieved using striped metas.

Yes, that doesn't disagree with what I said.  Concats are easier to expand, but striped will give you better performance in many cases.  If the IO load is light, the performance is likely to be the same.

"light","large","heavy"... all nebuous words that have little bearing in real life... my 'large' workload, is ~30,000 IOPS on a single host system... but I talk to other folks and that's a pittance, while others that's larger than their entire array...

If there was a specific guidline of the IOPS and MB/sec a single TDEV could handle, it would be easy to understand how many metas are needed, and when striping is appropriate.

This is what I presented at EMC World

Meta volumes may still be needed with VP

     For LUNs larger than 240 GB

     For any size host LUN that requires very high performance

          –LUNs doing 10s of MB/s or 100s of IO/s most likely would not need a striped VP meta volume for performance

          –LUNs doing 100s of MB/s or 1,000s of IO/s may need a striped VP meta volume for performance     

     If expansion is never needed, use a striped VP meta volume

     If ease of expansion is more important than performance, use a concatenated meta volume

I was in impression that, making stripe meta in VP will make the array busy where striping is already happening in Virtual Pool.
And again keeping in mind the limitaion of read and write is in per hyper.

Thank you much to all. My understanding in plain text is as follows from your comments:

Always go-go for stripe in VP as like disk provisioning for better performance.
Only in case meta expansion required in future, concat meta should be used.
Although for low used data concat meta would be better option, but who knows when a application or db becomes busy

When I read that stripping is better in "certain situations" and "run it by a performance specialist before doing" I take that as the exception and that concatenated is the norm.  Now thats how I read it and people can certainly have a different take.  I do realize that with how the queues work in the array there are some advantages to stripping, but it is dependent on what you are doing.  On the other hand you already are writing data across the TDAT's in 768Kb chunks so if you also stripe you have sort of gone plaid.

As with everything its situational dependent and having arbirtrary rules of we always do this one thing for every build is not the best method.