If you have allocated (from ESX perspective) all your space then that's a different issue.  ESX needs free space to work properly.  Temp files, swapfiles, logs and for VMware snapshots.   For example I typically create 600GB volumes (generally speaking) I leave at least 100GB free.  If that gets near, I create a new datastore and move VMs or just create the new ones on the new datastore.  Re: ESX knows.   Some SCSI/Disk basics.  At the disk level of storage there are no "files" there are only blocks.   Each block has an address, called an LBA, Logical Block Address.  So every volume(disk) reports it's capacity to the controller.     The volume(disk) starts at LBA 0 and goes to LBA      The ESX server keeps a table of the total blocks and when you do a write, it selects and LBA to use.   That LBA (and data) is written to the volume(disk).      The array also knows how big each volume is, so it knows how many blocks there are.   The ESX server sends the data with the LBA ESX choose to use, at the same time it updates the allocation table that's on that VMFS volume..  The array can  then locate LBA (X) and write the data there.    So since you handed us (X)MB, we can deduct that from the total volume free space.   Works great as long as you never delete anything.   A delete from ESX is a WRITE to the VMFS allocation table.  We record that write like any other.   There's nothing to tell the array, that LBA (X) is no longer used, so return it to the member free space.   That's where the new UNMAP command comes in.  Now the server can send us a command that says unallocate(free) LBA (X).   The in-use space will go down and free space on that member will go up.    re: Array reuse.   So since it's the ESX server that determines the LBA to be used, it will re-write LBAs as needed.    Re: Free space reporting.  No.  The important gauge is what the OS says, not the array.  Eventually when SCSI UNMAP is in effect those two will be much closer together.   If a VMFS volume goes to 100% you are in trouble.   ESX will no longer have a list of LBA to select from.  Writes will fail and VMs will go down.    The array in use is an aid to make sure you are not allocating more space than you actually have.  I.e. If you had a 2TB array, you could create a thin provision volume MUCH larger than that.  But until you actually write more than 2TB worth of data you're fine.  If you do, then the array runs out of space and volumes go offline and all the VMs would stop.  This gauge allows you to judge when to buy more storage.   So w/o UNMAP, eventually the EQL GUI will NOT reflect the correct free space for a volume.   Bottom line, follow what ESX (or any server) says about in-use and free space on a volume.  Better? 
Hi, I've got a very odd issue on a Loan SAN, I don't have the model number at hand at the moment but it's a PS6000 with NL-SAS disks. When I look in VMware at DRLUN01 it appears that there is only 149 GB free. When I look at the same LUN on the SAN it says that it has 985 GB free![IMAGE]   [IMAGE]  The SAN is running the latest firmware and is connected to an ESXi 4.1.0 server via iSCSI. The LUN contains Veeam replicas of my production systems. When I mentioned this to Veeam they advised that they have seen this twice but only know that Dell resolved the issues. As I'm not being offered any support, even though I'm likely to spend aout 20k with Dell and have Pro Support on my production SAN, I was wondering if anyone might have any ideas? Thanks Greg
LUN showing plenty of free space but VMware showing low on space!