Accepted Solution

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

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 Reportxml field
Volume NameobjName
Total SizedfKBytesTotal + volSnapshotReserveSpaceTotal
Allocated to LUNsdfKBytesUsed
Reserved for SnapshotsvolSnapshotReserveSpaceTotal
Unallocated SpacedfKBytesAvail
LUN Space UseddfKBytesData
Snapshot Space UsedvolSnapshotReserveSpaceUsed
Snapshot CountsnapshotCount

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?


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

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.

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

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.

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

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".