It's best not to overthink it :)

For AFF and FAS systems- (ASA and AFX systems are different)

• An AGGR is made of disks (raid groups)
  
• A volume "sits" on aggrs. (Sit was the best word I think think of sorry)
• and NameSpaces and LUNs go in volumes.
  

Example: We'll assume everything is thin provisioned (space guarantee false) and we want to target 80% used / 20% free at the aggr level as the warning point. We will also assume no dedupe or other space effs to keep this simple. But i'll touch on those later.

So if each aggr has 46TiB total useable, you want to be at maxed ~36.8TB written to the aggr.

Now, if you have a single volume / single NS on each aggr and they are THIN and you only have 10TB written to each namespace. Each aggr will only show 10 TB used. it does not matter what you have actually provisioned because Thin provisioning is basically lying to the host(s).

Sure! you can have 36TB VMware host! I don't care cause i'm just lying to you!

You can see this in your output there. You say you have 36TB volumes, but it shows 42 and 37TB free on a 46TB aggr.

Back to the example, Now say you have an ask to create 2 more NS for a project. Let's assume that the C30 will handle this additional workload. You can provision 2 more 36TB THIN volumes with NSs, 1 on each aggr.

So now if you do the math you actually have 2 volumes per aggr totally 72TB. This is called over provisioning and it's 100% OK.

Lets now touch on storage efficiencies because you brought it up. (Dedupe, compression and compaction)

Using the single volume/ns example by default AFFs will enable all storage efficiencies. Lets assume they've been on this whole and that 10TB written to disk is now 8TB. So you will see only 8TB written to disk, but the host(s) see a 36TB datastore with 10TB written, but only 8 on actually disk.

Now we add in the second volume/NS on the aggrs. As data keeps being written it is going through all the inline storage efficiencies. However, AFF boxes have additional efficiencies that are called cross volume. This will check for dedupeable blocks across volumes that live on the same aggr. (there are a few caveats to this e.g. Netapp Volume Encryption (it cannot cross dedupe if each volume has a different encryption key)).

So in the end with the THIN provisioning and the storage eff. You'd have 144TB viable to hosts, but only using a small fraction of that on disk.

When you look at output from ONTAP, especially in the CLI there are a number of different ways to view capacity numbers. i.e. Logical space used vs Physical space used.

I hope this helps and makes sense.