how a thin striped meta is layed out on a thin pool

Not really any different than a non-striped VP meta.  The VP pool is allocated across TDATs 768k at a time in a round robin fashion for both concat and for striped.

A striped meta switches volumes every 960k. 

The performance difference of striped vs concat metas on VP is not because of the backend but is because of the front end.  The backend is already striped.

The meta stripe is 960k.  So a host writing sequentially to a striped meta will write to a different Symm device every 960k.

Let's assume we have an unallocated pool and never written TDEVs and a 4 member striped meta and 8 data devices in the pool and I write 6MB (8 VP extents worth) The TDAT pool is allocated in 768k chunks.

So in this example, the first 960k would allocate 2 VP extents on two TDATs, filling the first completely, and leaving 192k free in the second.  Then the next meta member would do the same, and so on.

If the pool is pre-allocated, then none of this really matters.

I put a presentation together to illustrate this, but I can't attach it to the post.

Look in /incoming/Quincy56/Meta/

Quincy56, any way you can place the presentation on the FTP site.

I'd like to get a copy.

Thanks

Sent from my iPhone

Sorry to be pain but what is the full address i:e ftp

ftp.emc.com

There are several conditions in which the performance of concatenated thin metavolumes can be limited. Specifically:

1. Enginuity allows one outstanding write per thin device per path with Synchronous SRDF®. With concatenated metavolumes, this could cause a performance problem by limiting the concurrency of writes. This limit will not affect striped metavolumes in the same way because of the small size of the metavolume stripe (one cylinder or 1,920 blocks).
2. Enginuity allows eight read requests per path  per thin device and this limits the number of read requests that can be passed through to the thin pool regardless of the number of data devices that may be in it. This can cause slower performance in environments with a high read miss rate. This limit has been lifted in 5875 though.
3. Symmetrix Enginuity has a logical volume write-pending limit to prevent one volume from monopolizing writeable cache. Because each metavolume member gets a small percentage of cache, a striped metavolume is likely to offer more writeable cache to the metavolume.

There was an old recommendation of using concat metas because it used to not be possible to expand striped metas online therefore making concatenated more flexible.

Thanks Quincy, it has cleared my confusion.

From what I can see, Concat Thin meta and Striped Thin meta are both eventually striped on TDATs giving them more spindles, then why is Striped Thin Meta good for performance??

Also some of the post I read EMC recommends concat thin meta.

Concat metas are much easier to expand.  If you don't need to expand, stripe. 

Or if expansion is more important than performance concat.

There is limited concurrency for a single Symm volume with reads and writes to cache.  More volumes active at once increases the available performance to and from cache.

Quincy56 - any chance you can put that presentation back on the ftp site?

Thanks!

Quincy56

Having difficulty in understanding this. Can you please re-post the link to the presentation.

Quite an old thread resurrected.

I can't use the FTP site the way I did before.  If you would PM me with your email I can send it, or provide some other place for me to upload it.

Can you send the presentation to my personal email id

aalam.16@gmail.com

zigma6@gmail.com