Hey Julia,
There are a couple aspects here:
At the storage level, you may have:
storage pool unused - you have an aggregate, thin provisioning or some other type of pool where there is free space that you can allocate more volumes from.
Volume unused - you may have carved volumes, but they are not mapped nor masked to hosts - therefore, they can be presented to hosts as they are currently unused. Volume unused is becoming less common as the world has moved to thin provisioning, where you tend to carve exactly what you need. Before thin provisioning on platforms like Symmetrix and HDS USP, you tended to have an array that was pre carved, and it was up to you to hand out the slices of Wonder Bread.
On a volume level, OCI knows the capacity of the volume - this will be as seen by the host. OCI for many thin provisioning platforms will also know the "consumed capacity" of the volume - this is how much space towards the volume has been consumed by host writes + overhead.
The tricky part is that consumed capacity may have absolutely nothing to do with what the end user perceives as file system utilization. This is because a lot of file systems were not thin provisioning friendly. An example is NTFS (Windows standard for a decade), but other are similarly afflicted. Here is the issue - NTFS has a bias for writing new writes to new blocks on the file system, on the presumption that writing to dirty blocks (blocks free but have previously been written to) may be fragmented, resulting in poor performance (again, this was also somewhat presuming a world of spinning disk).
Anyhow, imagine this is the application behavior:
100GB volume seen in OCI, 0GB "consumed capacity" in OCI.
Nightly, the host application writes 10GB, parses it looking for a needle in the haystack, and deletes it.
If you are the application owner, at any point in time, you are likely to see either 0GB or 10GB for used capacity on that file system.
However, due to how NTFS tends to behave, the first 10GB of writes caused 10GB to be allocated to the volume, so OCI consumed capacity was 10GB.
Deleting that 10GB will not change that consumed capacity value - historically, hosts had no way to tell a storage array to deallocate those blocks that are no longer in use.
The second night, when 10GB is again written, NTFS has a bias against block reuse, so another 10GB will be allocated from the array.
So, as you can see, thin provisioned volumes have a tendency to become "thick", or fully allocated over time. To counter this behavior, there has been a lot of work in the industry for file systems and storage arrays to be able to communicate and be more thin provisioned friendly. However, where we are is still a world where what the array has had to allocate to the host may have little to no correlation whatsoever with what the end user / application owner sees for file system utilization on their host accessing the volume.
With all that said, OCI 6.4.1 has extended its model of a volume to support written capacity - some thin provisioning arrays seem to know how much data has actually been written to thin volumes.
See my post here on that topic - https://communities.netapp.com/message/115931#115931
