DF -g & getnasnapshot differences

[#1]

Hi all,

I am currently in the process of automating some capacity reporting but I have come across a discrepancy I can't work out why,.

When I run a df -g on a volume I can see the snap reserve is close to 4.5TB

/vol/*********/	7700GB	5061GB	2638GB	66%  /**********/
/vol/***********/.snapshot	3300GB	4643GB	0GB	141%  /vol/*********/.snapshot

When I run the following command in powershell

get-nasnapshot $vol.Name | foreach-object{$VolumeSnapSize += $_.Total }

$snapsize =  [Math]::Round(($VolumeSnapSize/(1024*1024*1024)),0)

It gives me at total of 7604GB.

Is this because of dedupe on the snapshots? I am stumped and it really throws my reporting out!

Appreciate any help

[#2]

Sorry, this probably isn't going be much help but I've tried your code against one of our volumes which has dedupe enabled and the output looks to be correct and consistent with ontap. This was against 8.0.3.

/vol/*******/	5120GB	2882GB	2237GB	56%  /vol/*******/
/vol/*******/.snapshot	0GB	985GB	0GB	---%  /vol/*******/.snapshot

Powershell output: 985

I've tried setting the snapshot reserve to various amounts to see if that was somehow throwing the output, it didn't make any difference, but then I wasn't really expecting it to.

Have you tried breaking down the output a little and checking the output on a per snapshot basis? Something like:

get-nasnapshot $vol.Name |

    foreach-object{

        $CurrentSnapSize = [Math]::Round(($_.Total /(1024*1024*1024)),0)

        Write-Host $_.Name " " $CurrentSnapSize

        $VolumeSnapSize += $_.Total

    }

Maybe a more verbose output will give you a pointer as to where it is going wrong.

[#3]

Hi Paul,

You definitely understand the problem correctly.  Summing the snapshot sizes won't take into account clones or dedupe, so you are likely to get a bad result.

Fortunately, you can use the "Cumulative" property to get the same output as the df command:

(Get-NaSnapshot myvolume | measure -Maximum Cumulative).Maximum

Or if you like formatted data sizes:

(Get-NaSnapshot myvolume | measure -Maximum Cumulative).Maximum | ConvertTo-FormattedNumber -Type datasize

That should get you within rounding error of the df command. 

Cheers!

[#4]

Thanks Eric, unfortunately still getting a completely different number!

ashley cook, I outputted the size of each snapshot which gives me the 7TB:

(0151748487)_prd_std_T3_b28_01_r.26705   13

smvi_Clayton-std-daily-01_novmsnap_20120609222000   219

smvi_Clayton-std-daily-01_novmsnap_20120610222000   223

smvi_Clayton-std-daily-01_novmsnap_20120611222000   476

smvi_Clayton-std-daily-01_novmsnap_20120613222000   256

smvi_Clayton-std-daily-01_novmsnap_20120614222000   296

smvi_Clayton-std-daily-01_novmsnap_20120615222000   491

smvi_Clayton-std-daily-01_novmsnap_20120616222000   394

smvi_Clayton-std-daily-01_novmsnap_20120617222000   249

smvi_Clayton-std-daily-01_novmsnap_20120618222000   275

smvi_Clayton-std-daily-01_novmsnap_20120619222000   234

smvi_Clayton-std-daily-01_novmsnap_20120620222006   337

smvi_Clayton-std-daily-01_novmsnap_20120622222000   403

smvi_Clayton-std-daily-01_novmsnap_20120623222000   224

smvi_Clayton-std-daily-01_novmsnap_20120624222001   226

smvi_Clayton-std-daily-01_novmsnap_20120625222000   343

smvi_Clayton-std-daily-01_novmsnap_20120627222000   258

smvi_Clayton-std-daily-01_novmsnap_20120628222000   256

smvi_Clayton-std-daily-01_novmsnap_20120629222000   365

smvi_Clayton-std-daily-01_novmsnap_20120630222000   265

smvi_Clayton-std-daily-01_novmsnap_20120701222000   136

smvi_Clayton-std-daily-01_novmsnap_20120702222000   143

smvi_Clayton-std-daily-01_novmsnap_20120703222000   137

smvi_Clayton-std-daily-01_novmsnap_20120704222000   139

smvi_Clayton-std-daily-01_novmsnap_20120705222000   151

smvi_Clayton-std-daily-01_novmsnap_20120706222001   242

smvi_Clayton-std-daily-01_novmsnap_20120707222000   153

smvi_Clayton-std-daily-01_novmsnap_20120708222000   139

smvi_Clayton-std-daily-01_novmsnap_recent   84

[#5]

Erick using this line: (Get-NaSnapshot myvolume | measure -Maximum Cumulative).Maximum I get the below:

prd_std_T3_b28_01:  7654244847616

[#6]

Very odd, I can't think of a reason for this.

What I was going to suggest was check the verbose output against System Manager, so you get a view of each snapshot and the cumulative total. I was hoping that might give you an indication of where the output was differing from ontap.

I don't think dedupe should be skewing the output. Certainly when I ran that code the figures returned reflected the dedupe savings.  What version of ontap are you running? Just thinking something in the API may have changed between versions.

[#7]

Hi Ashley, 7.3.6.

It's very weird as System Manager is reporting the 7TB as well...

	Data Space: 1.98 TB
	Snapshot Copies Space: 7.04 TB
	Snapshot Overflow Space: 1.67 TB
Total: 9.02 TB

Kind of throws out my capacity reporting completely...

[#8]

I'm stumped sorry. Maybe someone else running 7.3.x could take a look at their system to see if the results are consistent with what you are seeing?

I've seen disparity between what ontap and operations manager report previously, this has been where seemingly different calculations were used for the dedupe savings. Nothing quite like this though.

Sorry I can't be of more help.

[#9]

Yep it's got me completely stumped as well... Need to start again with my reporting and have a think how I can get around it.

[#10]

Just to throw another curve ball get-nasnapshotreclaimable (unfortunately this method is too slow if I was to use it across all filers) displays a different snapshot size (more consistent with df -g) than what is displayed in the get-nasnapshot and system manager!!

Very weird!