HPE Storage Users Group

Hi,

After running the unmap command on the ESX host, the Used User size reduced significantly, however the Reserved space on the VV is still the same and has a higher value.

I tried to run a compactcpg, and Inserv came back saying the CPG is already compact. I'm assuming the compactcpg runs automatic as I have the DO and AO license installed?

Can I free up chunklets and reduce the Reserved User Space value? Or is this just best left alone?

Thanks!

Hi,

the reserved space should be cleaned up by background process that is running automatically. In my experience this can take a very long time.
AFAIK there are no tuning commands or other tricks that would speed this up (we asked HP support as well). So if anybody knows another way or has more info on this I would be very interested as well.

I'm not at the version you guys are yet so I can't test myself, but is it possible the zero_detect policy needs to be enabled on the VV (LUN) inside the 3PAR?

Fastjack wrote:Hi,

the reserved space should be cleaned up by background process that is running automatically. In my experience this can take a very long time.
AFAIK there are no tuning commands or other tricks that would speed this up (we asked HP support as well). So if anybody knows another way or has more info on this I would be very interested as well.

Ok, I'll keep an eye on it. Hopefully the space gets reclaimed eventually. Thanks.

Richard Siemers wrote:I'm not at the version you guys are yet so I can't test myself, but is it possible the zero_detect policy needs to be enabled on the VV (LUN) inside the 3PAR?

Hi Richard - Yes the VV is 'zero_detect' enabled.

Richard Siemers wrote:I'm not at the version you guys are yet so I can't test myself, but is it possible the zero_detect policy needs to be enabled on the VV (LUN) inside the 3PAR?

All our volumes have zero detect enabled. Otherwise the used space within the volumes would not have shrunk leading to the large difference (used space vs. reserved space).

Fastjack wrote:All our volumes have zero detect enabled. Otherwise the used space within the volumes would not have shrunk leading to the large difference (used space vs. reserved space).

Good point.

I've seen similar "slow to shrink" behavior after manually zeroing out luns with sdelete, perhaps ESX and unmap are irrelevant details to the thin reclaim behavior you see. My hypothesis formed in my case was that there is an algorithm that prevents excessive allocation/deallocation work and to prevent excessive backend fragmentation of your luns.

Try running 'freespace' against the VV. You can't have snapshots when using this command.

AFAIK, compactcpg are not automatic but can be scheduled with createsched