One year ago, I wrote a piece about thin provisioning and the role that the UNMAP VAAI primitive plays in thin provisioned storage environments. Here’s an excerpt from that article:
When the manual UNMAP process is run, it balloons up a temporary hidden file at the root of the datastore which the UNMAP is being run against. You won’t see this balloon file with the vSphere Client’s Datastore Browser as it is hidden. You can catch it quickly while UNMAP is running by issuing the ls -l -a command against the datastore directory. The file will be named .vmfsBalloonalong with a generated suffix. This file will quickly grow to the size of data being unmapped (this is actually noted when the UNMAP command is run and evident in the screenshot above). Once the UNMAP is completed, the .vmfsBalloon file is removed.
Has your curiosity ever got you wondering about the technical purpose of the .vmfsBalloon file? It boils down to data integrity and timing. At the time the UNMAP command is run, the balloon file is immediately instantiated and grows to occupy (read: hog) all of the blocks that are about to be unmapped. It does this so that during the unmap process, none of the blocks are allocated during the process of new file creation elsewhere. If you think about it, it makes sense – we just told vSphere to give these blocks back to the array. If during the interim one or more of these blocks were suddenly allocated for a new file or file growth purposes, then we purge the block, we have a data integrity issue. More accurately, newly created data will be missing as its block or blocks were just flushed back to the storage pool on the array.
