HPE Storage Users Group

I guess "compactcpg" will do the job - will it decrease performance in any way? I hoped to find a way to shrink the disks on a vv basis, but seems to be the only way to compact the whole cpg(s). I'll try this the next days.

CompactCPG is best after you delete VVs, or "tune" them out of a CPG... it will not "thin reclaim" individual VVs for you.

If HP-3PAR is listening, will you guys build a thin reclamation component into Host Explorer that can be triggered from the Inserv its connected to? Pretty please? Pretty sure Netapp has had this for quite some time now.

Sorry, was very busy the last weeks.
Finally, I had now time to do some tests:
Created a new (thin, zero-detect) VV (size 10 GB), exported to linux host (SLES 11 SP3) with lvm and ext3 filesystem. Separated into 2 LVs with 5 GiB each.
Allocation: 2,250 GiB (1 GiB User Space, 1 GiB Copy Space, 0,250 GiB Admin Space)
Copied a zero-filled 2GB file -> didn't reclaim any space on 3PAR as expected.
Deleted that file, copied a 2 GB file with random data -> reclaimed additional 3 GB (User Space) on 3PAR (yes three GiB). Hm, okay...
Deleted that file -> spaces stays allocated.
Did a fstrim on that volume -> spaces stays allocated.
Created (dd) a 5 GiB zero-file on that volume -> spaces stays allocated (but doesn't increase).
Compact CPG doesn't work ("CPG is already compacted"). Any way to get that space back on 3PAR?
Or do we need AO (tunevv) to get that VV small again?

Btw: When creating a physical copy the copy is thin again, so 3PAR recognize the zero filled space.

Maybe it's just some problem with ext3 or SLES? Unfortunatly, ext4 isn't supported (only readonly), so I can't check that.

Netapp do have that option using the snapdrive agent for Windows, but I'm reliably informed it will peg the controller CPU's at 100% for long periods of time, meaning it's a definite out of hours process needing to be scheduled on each host and provides very inconsistent reclaim results.

Interesting idea to integrate with Host explorer though, but I have to admit I don't really favor adding proprietary host agents to bolster storage functionality. Once you introduce them it's just more for Customers to maintain in the support matrix and can inadvertently lead to "lock in" if processes become over dependent on the functionality.

But both EMC and Netapp tend to do this quite a bit, so maybe the added functionality is worth the lock in ?

Sure, as long as the agents are optional and not required to use the storage. Some places are dead set against deploying agents, so be it... but perhaps where permitted, certain clients/apps that would benefit from a thin reclamation could be cherry picked, if not an all out rollout across the board.

I do think the need for this will diminish over time as newer filesystems start to work like VMFS in ESX 5.0 and use the T10 unmap command.

Agree but it's probably too late, the problem is that such a feature would only really serve legacy operating systems, so it's unlikely HP would divert development for what will in reality be an ever shrinking market.

The reason some of the T10 features aren't quite up to scratch at the moment is that the O/S and Hypervisor vendors have to limit the aggressiveness of reclaim to the lowest common denominator array's functionality. Mentioning no names, but many legacy arrays employ fixed data constructs and also don't support true inline zero detect, so deleted data can't really be reclaimed back to the system as a whole and typically not in anything like real time. This means the reclaim has to be staged in small increments to avoid impacting performance on these arrays regardless of what 3PAR can do natively.

BTW The windows 2012 T10 (Trim/Unmap) support is really well implemented, it also reclaims as part of the dedupe and compression process not just your typical deletes