IBM Storage The online community where IBM Storage users meet, share, discuss, and learn. Join the Community
Hi,on newer firmwares there are two commands
SCSI Unmap can be disabled using the CLI command:svctask chsystem -backendunmap offsvctask chsystem -hostunmap offTo re-enable SCSI Unmap, use thesvctask chsystem -backendunmap onsvctask chsystem -hostunmap onOn Standard pools you will only see that the used capacity of the FCM goes down, not the size of the thin provisioned volumes.
will there be a change in the behavior in newer versions as this is pretty ugly?
#On Standard pools you will only see that the used capacity of the FCM goes down, not the size of the thin provisioned volumes.#
this won't change for standard pools, i.e. non-DR-pools, as those do not support SCSI UNMAP at all.
------------------------------Sebastian HofmannOriginal Message:Sent: Tue October 26, 2021 03:54 AMFrom: Bernd AlbrechtSubject: Flashsystem host unmap not working ¿?
this is not correct. STD Pools support SCSI UNMAP ... but the Volumes in the Pool do not show the reclaimed Space. The Pool usage will go down if eg a big VM is deleted
what is happen on happen on STD pools is, the SCSI UNMAP free up the blocks on Flash drives internal. On Flash less physical Storage is used. On FCMs is what you see on pool usage. Best regards.
a simple and accurate answer
Not entirely accurate.All pools support the host unmap commands. DRPs track and account for capacity changes as a result, standard pools do not and cannot (That is the primary difference and the purpose of Data Reduction Pools).
thanks for clarification. TBH the implementation on STD Pools is pretty ugly. As per my knowledege ( using FCM3 module ) its better to utilize STD Pools ( no dedup & no software compression ) also what i faced is that creating a LUN in a DRP pool u need to utilize either Compression and / or Dedup. Is there a way to utilize DRP Pool without software compression and deduduplication ( only the native FCM compression )
Keep in mind that Standard or Legacy pools as we sometimes call them are about over 20 years old. The technology pre-dates the unmap command and even flash in enterprise storage, and thin provisioning was added to it long before it was industry standard.
The architecture required to do the tracking for capacity at this level is a log structured array, this data structure is what is used by the FCMs themselves and by the Data Reduction Pools. DRP exists BECAUSE of this problem, the original name for DRP internally was "Unmap".
In Software, it is this log structured array that adds latency to a DRP overprovisioned volume because of the transformations and the io amplification required to keep the meta data updated (not the compression, not the deduplication, those are all offloaded to the Intel Quick Assist Compression Offload Hardware on all boxes except the 50XX).
So in answer to your original question: If you require capacity returns reported at the pool level in a FlashSystem Box, you need to use Data Reduction Pools with overprovisioning ( Because a fully allocated volume is ALWAYS a fully allocated volume regardless of it's pool, it will never return partial capacity to the pool).If your workload is unsuitable for DRP, then the recommendation is to be aware of the behaviour (as you are now) and know the new capacity will be taken from unmapped capacity first, and as I said before, the re-thinning technique works for folks who are concerned about a lot of unmap without overwrite.
For capacity planning in general, there are some very good practices, foremost is getting SI as it comes included with your FlashSystem and can provide a lot of capacity tracking information.
I'm trying to convince Barry and Andrew to put their very good advice on how to manage this better in their blog, so keep an eye out for it.I hope that helps.