Thanks for the quick reply Dyna,

So in this caseRAID group that I know is that fixed and cannot be expanded dynamically.

while the Pools can be expanded for both Thin and Thick pools. (for each LUNs created over the Pools there will be 3 GB overhead metadata in use).

cmiiw

take a look at this paper, covers a lot of stuff

White Paper: EMC Unified Storage Best Practices for Performance and Availability: Common Platform and Block Storage 31.5 — Applied Best Practices

Some searching here in the forum wouldn’t hurt either – it’s a very frequent topic lately

you can no longer expand raid groups, but you can continue to use raid groups and MetaLUNs to give you expansion options. Unless you must have total control of data placement, i would not consider traditional raid groups anymore. The latest VNX OE release provides so many enhancements to how pools get expanded, rebalancing ..etc that to me traditional raid groups are things of the past

Traditionl LUNs on RAID Groups will still outperform Pool LUNs (Thick or Thin) as they do not have metadata overheads.

That said, they are inflexible when compared to Pool LUNs and therefore have few valid use cases. You should only use them when you want deterministic performance, are required by underlying features and you understand the features/workload well enough to manually tune tuem. 

If most environments Pool LUNs are the recommended approach. 

Thanks for the reply Chris,

So apart from the additional 3 GB metadata , Pool LUNs is fine and better for the VNX environment as it can be extended on the fly without causing any downtime ?

Pools should be the default approach.  Traditional LUNs should ONLY be used when you have very specific requirements (performance or otherwise). If you dont know what such requirements are, chances are you won't need to use them

Chris,

Is there any whitepapers which compares about the performance difference in using Thick Pool LUN versus RAID group ?

What could be the performance benefits ?

there should be someting in this paper, 10% performance hit of pool LUN vs traditional LUN

White Paper: EMC Unified Storage Best Practices for Performance and Availability: Common Platform and Block Storage 31.5 — Applied Best Practices

10% for IOPS sounds about right. Of course your mileage will very depending on the actual workload profile.  

Also pre-Inyo ThickLUN space was reserved not allocated, so there was some degree of locality of reference at play as well.

AlbertWT, just stick to pools unless you have specific requirement .  The flexibility pools bring will outweigh the performance benefits of using RAID Groups.