When a thin LUN expands, what tier does it expand onto?  I assume it is based on the pool policy (highest first recommended) but cannot find this anywhere.

    Not sure on this as Thin LUN expansion is on-demand - the space required is subtracted from the total available, but the actual slices are not pre-allocated. As you use the expanded space it probably uses the start High, tier low policy, but I have not found a definitive answer on this.

If you create a thick LUN of 100 GB and are only using 50 GB, wouldn't the unused 50 GB be sitting in the SATA (or lowest) tier?  Then say a data load has to occur and then will be used for reports and fills in 25 GB.  The performance of this data would be terrible until the next scheduled relocation which typically only happens at night.  Is that performance penalty better/worse/the same compared to the performance penalties that cause EMC to recommend thick LUNs for performance?

     In flare release 31, Thick LUNs were allocated the same as Thin LUns - the space was subtracted from the total available, but the actual slices were assigned when needed. In flare 32, when you create a new Thick LUN, all the slices are pre-assigned. This is to keep all the slices on the same SP when the LUN is created, to prevent some slices from being assigned to the peer SP (this can occur under certain circumstances). This helps improve performance.

glen

To add to Glenn's comments, the main reason for the performance difference between thick and thin LUNs has to do with the 8KB granularity of thin LUNs versus the 1GB for thick LUNs.  This means for the same 1GB slice, there are more metadata lookups required for a thin LUN.  As is well-known by now, both thick and thin LUNs are allocated in 1GB slices, and in the case of FAST (VP), tiered in the same 1GB slices; however, thin LUNs have the "overhead" of 8KB granularity.  The reason for this is that compression becomes viable as there is a greater chance of finding commonality.  As a reminder, if enabling compression on a thick or a FLARE (traditional) LUN, it ultimately becomes a thin (pool) LUN by way of a LUN migration initiated first by the system.

As already mentioned by Glenn, with VNX OE for Block v31 thick LUNs were still allocated on demand in the same 1GB slices.  Therefore, it was more-or-less incorrect to suggest that the performance deltas between thin and thick LUNs was due to the initial overhead of having to lay out the slice first.  Even then, it was only a one-time concern as once allocated, writes thereafter didn't have this overhead.  Therefore, with VNX OE for Block v31, we may have gone as far as suggesting performing full formats of thick LUNs and may have also taken it a bit further and suggested in the case of multiple LUNs, performing the full formats simultaneously so that the stripes were interleaved.  Now, with VNX OE for Block v32, thick LUNs are now fully allocated (and as was always the case, the space is reserved, and the array LBA's are assigned sequentially which also contributes to the performance deltas).

To assist with "metadata acceleration" (borrowing a phrase from Isilon), as noted in the "EMC VNX Unified Best Practices for Performance: Applied Best Practices Guide":

[...]

• Thin LUNs are recommended when storage efficiency requirements outweigh performance requirements.
  • When using thin LUNs, adding a small Flash tier to the pool can improve performance

               - Thin LUN metadata is promoted to the Flash tier

[...]