2014-01-20 12:01 PM
A colleague of mine has some code that loops through each volume in an aggregate and performs a "get-navolsize".
However, when we tally this, it ends up being about 30TB.
When I sum these from vol size from the CLI and then doing the conversion to KB, I end up with 36TB.
DFM 5.0 shows "Storage Capacity" "Volumes" as being 34TB, so I believe that there is some KB/MB/GB/TB differences between this as the 2nd method listed above. However, I would think that this would correlate with the API call.
We did show a warning that we had an aggregate overcommitted with 29.5TB. We suspect that this part correlates with the API, but given the date of the alert, maybe/maybe not.
Question: Why doesn't get-navolsize and vol size from the command line correlate? What may we be missing?
P.S. this is for OnTap 8.1.* 7-mode.
2014-01-23 07:11 AM
I'm an extensive user of the powershell toolkit as well as DFM. I'm going to review this b/c I'm not sure i'm seeing this issue.
Also, this might be better directed in either one of those forums
Just clarify for me, what view in Ocum are you seeing the difference, is there a report you ran
2014-01-23 09:45 AM
Ok, so I ran through what your seeing
Get-navolsize is essentially getting volume size like vol size command on cli. The report which you are looking at is only giving you what the filer counts to the Active file system, meaning it doesn't calculate in the snapshot reserve
A get-navol command should match which is in DFM. I tend to code with get-navolsize for true representation
2014-01-23 10:06 AM
Sorry for being unclear...
In most cases, we see get-navolsize as reporting appropriately, but on this particular HA pair, it does NOT correlate to the CLI data or to DFM. I can't understand why. My expectation is that it would match the CLI, hence the opening of this discussion.
Sounds like from your testing and understanding, get-navolsize correlates with CLI as well, and should.
At least, my understanding on proper behavior has been confirmed.