All SolidFire volumes are thin provisioned so the volumes do not reserve the physical space on the storage at creation and only consumes physical space as data is sent to the volume.
Reduction in volume size should be a file system level activity because different host OSes handle volume reductions differently or don't handle the size reductions at all.
For example, a user will cause file system corruption if he or she decreases the volume size at the storage level to less than the physical size that th file system has actually consumed such as trying to shrink a volume to 100GB when the file system already had written 120GB to the volume.
As another example of a host restriction, VMware does not allow a user to shrink the size of an existing datastore. Instead, the user has to create a new datastore of a desired size and copy data from the old datastore to the new data store.
https://kb.vmware.com/s/article/1004510
By not allowing a user to reduce the volume size on the storage side, SolidFire volumes can be more file system friendly for all file system types.
Reclaiming space within an existing volume after a host deletes data is accomplished with scsi unmap.
Team NetApp
