Jason,
#1. Only volumes that have been assigned a tiering policy will have a bin0 (AFF storage) and bin1 (object storage) and then "volume data footprint" should be the sum of those two.
If you are dedicating a page to volumes that are under fabric pool/tiering policy, then I'd exclude volumes that do not have bin0 and bin 1. That gives us a place to report and easily analyze individual bin 0 and bin 1 numbers as well as sum them for an aggregate or cluster. I hope that makes sense.
If you are adding this info to an existing page, just leave those blank or 0 if that is possible (if they have no bin0/bin1) but you could still report on volume data footprint, but imagine you report on this already.
#2. If you can validate that bin0 will always be the SSD aggregate and bin1 will always be the object store, you could label them:
bin0 = SSD
bin1 = Object Store
or generically:
bin0-name,bin1-name
this translates to the following output in the CLI which would provide the actual name of the SSD tier or Object Store tier:
cluster1::*> volume show-footprint -vserver svm1 -fields bin0-name,bin1-name
vserver volume bin0-name bin1-name
------------- --------- ---------------- -------------
aitmokcc-svm1 NAS_AUDIT Performance Tier fabricpool
#3. If you capture this info elsewhere, then no reason to duplicate....the primary goal of collecting this data is to be able to easily break down how much data is remaining on SSD and how much is moving to the object store. If we run it regularly, then we can see trending for individual volumes. Maybe someday they could capture this in OCUM...
For sure, the rest of the data has less value to me for my purpose.
I sent you info about our environment to your LinkedIn to keep it off the public internet.
Thanks for all your help!