White space and VMware

Right I got that, so bottom line is the OS will still be able to write a file on blocks that are available, but that the compellent sees as "in use", correct?

SAN storage is a block level storage device, not a file level storage device (that would be a NAS).

What this means is that it looks at the writes as 'raw' data. When a server 'deletes' a file, it doesn't go out and delete the actual file, it just marks the disk space as being available for something else to be written there. The SAN doesn't know this and still sees the zeros and ones that make up the original data.

With the unmap option the OS can tell the SAN/storage solution that that space now no longer serves a purpose and can be considered 'free'.

also, I am not in a position to run UNMAP at this point until I get some patches and upgrades on my esx host to fix some unmap issues. I just want to make sure I can rely on the free space that vmware host is reporting, and not the compellent. Thank you.

Thanks Michael. Once I get U2 on for 5.1 that has more stability in using unmap I am told, I will start clearing my white space. I just wanted to confirm I am not going to run a vmfs volume out of space if Compellent reports way less free space  that what an esx host reports. So I am just assuming even though compellent will see some blocks that are "used" and not free in the pagepool, that esx will still write over them since esx knows those blocks have been freed up.

I dont mind the comments - just want to ensure I am clearly communicating.

The value proposition of having the OS and the Storage linked (using VAAI or some other connection) is that while the OS may know that the space can be reused, if the storage is unaware then you are reserving a valuable asset (the storage) on what is essentially nothing. The same thing can be said for storage systems that do not use thin provisioning features - once you commit the space into a LUN - even if you dont use it - its allocated (and used).

This is a waste of money - both with the economics around the cost per GB and with the additional labor administrators have to spend keeping such systems balanced and/or LUNS utilized as best as possible. If I reclaim the storage at both the OS and storage system level then I can re-purpose those blocks to the best needs of my organization (possibly avoiding additional space purchases) and still have the advantage of the system handling that automatically vs a manual administrative task.

For the general purpose world - its annoying to know that your space is being wasted in the same scenario that would happen if users backed their hard drives up to general purpose file shares :)

Also my last comment on this I promise :) But I guess I am missing the big picture. If esx can properly keep track of the free space and what blocks to write to, what is the real point in reclaiming, aside from having the compellent report the correct space usage?

Has anyone ever issued an unmap with vmkfstools? I know this procedure has become better in esx 5.5, I am still on 5.1 unfortuneately. And to be honest the procedure really scares me, because there is not way to throttle it and who know what kind of load it is suddenly going to put on your array. Thank you.

Thank you very much Michael. One I get to U2 I will run some test reclaims on our development compellent to see how much it is impacted. Thanks again.