Getting the value for the amount of space in a volume being used by files?

[gunthermontez]

I'm trying to get a report that breaks out the following space usage values for each volume: Allocated to LUNs, Reserved for Snapshots, Unallocated Space, LUN Space Used, Snapshot Space Used, & Snapshot Count.

The tricky value seemed to be getting LUN Space Used (how much space in the volume is being used by data and/or files). In most reports that have any kind of "Space Used" value, it refers to how much space in the volume has been allocated to LUNs, I'm trying to get a report that also gives an indication of how full those LUNs are. Then I thought I had found everything I needed by scheduling the Volume Space Breakout report (in Operations Manager) to send an xml file that included all fields, I was able to map the fields like so:

My Report	xml field
Volume Name	objName
Total Size	dfKBytesTotal + volSnapshotReserveSpaceTotal
Allocated to LUNs	dfKBytesUsed
Reserved for Snapshots	volSnapshotReserveSpaceTotal
Unallocated Space	dfKBytesAvail
LUN Space Used	dfKBytesData
Snapshot Space Used	volSnapshotReserveSpaceUsed
Snapshot Count	snapshotCount

This initially seemed to work, but then I noticed that some of the LUN Space Used values were no longer accurate after a day or two, they had a value higher than they should've been (e.g. the report would show "4 GB" when all the files actually added up to 3 GB). It seems the dfKBytesUsed field in the xml report only increases in value, never decreases, so my report ends up showing a "high water mark" for each volume instead of a current value.

Is this a bug in the Volume Space Breakout report? Or am I misunderstanding what the dfKBytesData field actually refers to? If so, is there a field in a different report that will get me what I need?

Thanks!

[smoot · Accepted solution]

I can't remember the details of the arithmetic involved in those fields but I suspect you're right. The problem is, once your host file system deletes a file, ONTAP has no idea those blocks are unused. As a result, they're still allocated as data blocks on disk and show up in the accounting that way.

If you're attaching from Windows systems, I thought SnapDrive for Windows had a way to tell ONTAP which file system blocks were unused so they could be freed on the storage system (this went by the name of "hole punching"). I don't know if SnapDrive for Unix has a similar feature. Once you hole punch the LUN, dfKBytesData should accurately reflect the used space in the host file system.

Finally, you might want to try configuring the file SRM agent to walk the host side file system to give a host side view of how much space is used. You should be able to construct a report correlating what FSRM reports against what ONTAP reports. I personally have never tried this so I can't help you much more than that.

[gunthermontez]

Thanks, your explanation made complete sense. In SnapDrive for Windows I was able to run the Space Reclaimer on a LUN and sure enough the dfKBytesData value in the report dropped back down. I'm not sure if there's a way to have the Space Reclaimer run automatically at a specified time (or if that's even a good idea), but at least I understand now what's going on. And the SRM agent idea is interesting, I might dig into that further.

[smoot]

Glad it helped.

I don't know if running a space reclaimation on a regular basis is a good idea either but I can't see how it would hurt. The simplest method is to use the Windows scheduler and "sdcli".