Subscribe

Aggregate capacity methods are showing different results

[ Edited ]

I'm trying to validate the methods used to calculate aggregate results in 7mode. I have three methods of checking capacity info on aggregates; aggr show_space, ds -Ah, and the ontap API. I executed each of these methods at the same time, and the differences between the results should only be a few MBs off at most (given the use of the volumes and the few seconds it took to run each command). However, each method is showing a few TBs difference (especially when using df -Ah).

 

With that said I have a few questions:

  1. Why are all these methods showing different results? If they should be equal, then what might be causing this difference?
  2. Which filer commands does the aggregate API use for calculating aggr results? If no filer commands are used, then what is the process used by the API to calculate these results?
  3. How can I properly and accurately calculate aggregate capacity information using the API (excluding WAFL and snapshot reserve)?
  4. Are the answers to this question the same in cDOT? If not, what are the differences between these answers in 7mode and cDOT.

My results are copied below.

 

aggr1:

 

filer command > aggr show_space:

UsableTB: 110.54115880000001
Allocated TB: 75.974546336
Used TB: 25.0580319
Avail TB: 34.564185584

filer command > ds -Ah:

Total TB: 102
Used TB: 70TB
Avail TB: 32TB

aggr API > aggr-list-info:

Total TB: 113.194146611199997
Used TB: 77.800420732928004
Avail TB: 35.393725878272001

aggr0:

 

filer command > aggr show_space:

Usable TB: 1.052772952
Allocated TB: 0.424975816
Used TB: 0.014768576
Avail TB: 0.62420092

filer command > ds -Ah:

Total TB: 1.004
Used TB: 0.408
Avail TB: 0.595

aggr API > aggr-list-info:

Total TB: 1.078039502848
Used TB: 0.438857773056
Avail TB: 0.639181729792

 

Thanks in advance,

Zach

Re: Aggregate capacity methods are showing different results

These results were incorrectly calculated on my end by using the google tool incorrectly. I was converting to TB instead of TiB, which was using the method "1000*1000*1000*1000" instead of "1024*1024*1024*1024".

 

Thanks to Mike Arndt for this find.

 

Zach