You can form a non meta device already bound to a pool into a concatenated meta. (I think it requires 5875).  Since even concatenated metas effectively touch every disk in the thin pool, the performance difference isn't as drastic as a concatenated vs striped meta on a clariion.

Concat and Striped both can be expanded online in VMAX. I know expanding a LUN in CX is far easier than in VMAX but you can certainly do it.

You are using pools so you shouldnt have any trouble growing a windows lun.  In 5875 you can take a non-meta device and turn it into a meta volume as a way to grow it; 5874 the device had to be a meta before being bound to a pool.  With pools you should be creating concatenated meta-volumes anyway as the data is already striped across the TDAT's in the pool.

Take a look around powerlink for virtual lun migrator as well.

RobertDudley wrote:   With pools you should be creating concatenated meta-volumes anyway as the data is already striped across the TDAT's in the pool.

no necessarily, we had discussions with our TC and SPEED guys and striped is still recommended.

Can you elaborate on this?

I don't see any option in SMC to grow a device.

Assuming this needs to be done with symconfigure, can you let me know where this is covered in the documention?

wonder if you have to upgrade SMC to 7.2 to take advantage of new features in 75.

Agree with Dynamox, striped thin meta gives better performance than concat thin meta in some cases...I guess earlier the main reason for recommending concat thin meta coz there was no way to expand the striped thin meta using protect data option...?

just my thoughts...

regards,

Saurabh

75 is only supported with SMC/SE 7.2 or higher...trust me i have seen some real issues if you try to manage 75 with version below 7.2

So which is it?  Stripe metas in a thin pool which is then striping the data twice or as the EMC person put it "in some cases performance is better".  What are the cases where striping a meta in a thin pool results in better performance?  What are the dependencies?  Pool size, data type, data base type, host type etc.

I have had some conversations with incredibly talented performance people from EMC that gave the do not stripe recommendation.

A single logical Symmetrix logical volume cannot deliver the performance of a large backed thin pool.  Say you have an eight engine VMAX with 2400 drives capable of delivering 100s of thousands of backend IOPs.  We know we cannot get all those IOPs through one logical volume even if it was presented on all available FA paths.

So for a host LUN that requires very high performance, you may still need a meta volume, even with a wide striped VP backend, or a host based striped volume over many Symmetrix logical volumes.

As to expansion, you can now expand a striped thin meta on VMAX with 5875 code, but it requires a thick BCV meta that matches the configuration of the thin meta you are trying to expand.