Why does df -s and sis stat give different % save?

[RichardSopp]

Comparing the output of the df -s command and the (diag mode) sis stat command I get two different results for % saved.

df -g -s vmware01
Filesystem                used      saved       %saved
/vol/vmware01/          628GB      498GB          44%

sis stat /vol/vmware01
Path                                 Allocated          Saving          %Saved
/vol/vmware01                     302 GB          498 GB            62 %

Can someone comment on why this is the case (while avoiding any comments of why I shouldn't be using diag commands) ?

[RichardSopp]

BTW: there are four weeks of snapshots on the volume as well.  Not sure if that would account for the difference in command outputs?

[pascalduk]

richardsopp wrote:
BTW: there are four weeks of snapshots on the volume as well.  Not sure if that would account for the difference in command outputs?

That could be the reason if those snapshots use more space than is present in your snap reserve.

https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb44652

Symptoms After licensing, enabling, and running sis start -s on a volume, there is a discrepancy between the output of the diag command, sis stat -l, and df -s.

Cause of this problem This typically occurs when snap reserve space is overflowing into the active file system.

[RichardSopp]

Thanks Pascal.

Considering VMware best practices involve setting the snap reserve to zero this makes reporting on de-dupe savings interesting.

Technically if sis stat gives the true accurate de-dupe rate then aren't we selling ourselves short if we use df -s for reporting?

(rhetorical) Wonder which one Operations Manager 3.8 uses for reporting?  Will need to check in my lab.

[pascalduk]

The allocated in the "sis stat" output looks to be the data in the live filesystem. The used in "df -s" is live filesystem + all bytes above the snap reserve. Personally I think specifying the saving against only the live filesystem is the best way. Iif you did not have any snapshots in the volume this will be the true savings.

I am not using OM 3.8 yet, but plan to upgrade in the near future because of a-sis report. Therefore I am also curious what OM uses

[RichardSopp]

FWIW: I finally got around to testing with with 3.8 and the saving value in the volumes-dedupe-and-lun-file-clones-space-savings report is the same as the sis stat output.

[pascalduk]

richardsopp wrote:
FWIW: I finally got around to testing with with 3.8 and the saving value in the volumes-dedupe-and-lun-file-clones-space-savings report is the same as the sis stat output.

Thank you for the information.

[bjornkoopmans]

The terms used to describe the fields in both commands gives a clue as well on how to interpret the data.

Used = space actually used by data in the volume. That includes LUNs but also snapshots outside the snapshot reserve.

Allocated = space which is appointed to the LUNs (snapshot-space outside the snapreserve obviously isn't appointed/allocated)

This is another example of these 2 terms being easily mixed up.

By the way, not all documentation agrees on setting the snapshot reserve to 0%. In fact, I found that a number of papers describe conflicting optimal settings, which makes it that much more difficult to find teh 'perfect' solution for your environment.