Reclaim using UNMAP on a Dell Compellent

[jedijeff]

Hi. Has anyone successfully reclaim space? It seems for me sometimes it works and sometimes it doesnt.

We are on vSphere v6.5 and SCOS 7.3x.

I know the automatic UNMAP will not work because of the supported block size the auto unmap needs and Compellent doesnt use.

But the cli esxcli storage vmfs unmap should work right?

So I had a 2TB volume which I emptied of a single VM awhile back. So VMware reported 2TB of 2TB free.

Compellent shows 160GB that was sitting on Tier3.

We have 2 replay profiles on each datastore. 15min with 1hr expiration. And 24hr with 48hr expiration.

So earlier today I tried to reclaim it instantly, and this should work.

ran the unmap command from a hypervisor

Took a manual snapshot of the datastore

Then expired all other snapshots

At this point the space should have been reclaimed right?

[StephenMoll]

I have been tinkering with a Compellent SC4020 SAN recently, and trying to understand these sorts of behaviours. Unfortunately I have started from a position of having a rather sickly SAN, and trying to build an understanding of how it got that way, and how to recover it, if possible.

At the moment I am not convinced that iSCSI UNMAP within the VMFS Volume, triggers a corresponding return of allocated disk space to the Volume on the SAN to the "Free Space" on the disks.

I am wondering if the freed up space of a Volume remains allocated until the controller decides it needs the space for a different volume, which in theory should never happen if the Volume sizing doesn't exceed the "Available Space". On top of this bear in mind that the configured space for volumes will be less than the space allocated to it on disk, which will vary depending on how the Active Space is distributed between the Tiers and RAID levels.

[jedijeff]

I think it actually maybe that the default SCOS data page size is 2MB. And vmfs6 wont unmap anything over 1mb.

Thats is my theory and I need to confirm with support.

[StephenMoll]

I agree. I have a 24TB SAN with 2 Volumes, one 7TB the other 3TB. Both of them are less than 4% full, and yet allocated disk space is currently over 80%.

I ran unmap commands in a loop on two hosts, one per Volume for over 24 hours, and... nothing. The SAN did have some underlying problems which have just been resolved though, which I hope will lead to some space being freed up as data progression occurs. There were some old snapshot reservations hiding in the SANs for Volumes that had been deleted 2 years ago. They ended up causing RAID rebalance to stop working, as it thought the disks were full.

[jedijeff]

This appears fixed in Update 2. I am still on update 1.

In VMFS-6 datastores, if you use the esxcli storage vmfs unmap command for manual reclamation of free space, it might only reclaim space from small file blocks and not process large file block resources. This issue is resolved in this release.

[StephenMoll]

We are looking into moving onto 6.7, but it will be some time before I can get to us sit in earnest.

I am hoping to get it onto the 'sandpit' rig first, so I can see what improvements there are in several areas, and the interaction with the Dell Compellent SANs is one of those.

I have spent some rather interesting time over the last couple of weeks getting down into the weeds of the SCOS CLI, resolving some issues. There is some good stuff on the CLI but it's a bit of a jungle in there and not for the feint of heart. The 'sandpit' had to be cleared of important stuff when I started getting nervous.