If you need to clear up space on your Nutanix cluster you may be considering removing local snapshots, but what if the reclaimable space is displayed as “Processing”? What can we do about it, and how can we know if a snapshot is worth removing?
The reclaimable space is subject to change and has to be totaled up before it can be known. This work is done during the same periodic filesystem scans which drive disk clean-up, post-process deduplication and compression, and information lifecycle management. Generally speaking we just need to wait for the next periodic scan to finish and then we should have the reclaimable space figure shown in Prism. If you need to estimate reclaimable space in the meantime, I can offer a few hints to help narrow that estimate.
It helps to have a little understanding of how snapshots work, and how the reclaimable space number is identified.
Think of it this way. Each current filesystem block has one or more owners, and any block cannot be deleted until no more owners of that block exist. The initial owner of a block is the file for which it gets created. After this, new owners can be added through snapshots, cloning, and deduplication. Ownership is removed when the block gets overwritten in the active filesystem (original file or clone), or when a snapshot is deleted. A filesystem block isn’t eligible for deletion until it has no owners. The reclaimable space of a snapshot, then, is the total space occupied by blocks which only belong to the snapshot. The article “Snapshot Exclusive Usage not matching sum of Reclaimable Space of all Snapshots” provides some further insights on this including a visual aid showing which blocks could be deleted in a common scenario.
New snapshots are fairly easy to estimate. If you consider that a snapshot is precisely equal to the active filesystem state of included files when it is created, you can understand that the reclaimable space of a snapshot at the time of creation is always zero. This is because every single block owned by the snapshot is also owned by the active filesystem. For a snapshot that was recently created, the reclaimable space field will probably show “processing” for a few hours but we can understand that unless significant deletions or overwrites have occurred the reclaimable space for a recent snapshot would be quite small.
For snapshots before the latest snap, if the rate of new writes to disk is fairly constant then snapshot reclaimable space should be nearly constant. There are exceptions, such as the latest snapshot which would show a smaller reclaimable space until the snapshot interval is concluded, or a snapshot that has been used for cloning.
Reclaimable space for older snapshots will fluctuate much less but can still change. If a clone is created from VM files in an older snapshot we would see a reduction in reclaimable space for this snapshot because we’re adding an owner. If a previous or subsequent snapshot is deleted, any blocks that were only owned by the snapshot in question and the deleted snapshot will become exclusively owned by this snapshot, thus increasing the reclaimable space. While changes from other snapshot removals may be harder to predict they are often small compared to the reclaimable space of each snapshot. Most of the time older snapshots already list a reclaimable space figure, and If the change is significant we should see an update after the next filesystem scan.