Get-NaLun reports SizeUsed > Size

[tom_maher]

We're using the toolkit (1.3.0.130) to get LUN usage stats from our iSCSI-mapped LUNs and are seeing some strange behaviour in the Get-NaLun cmdlet, namely that the SizeUsed property returns a higher value than the Size property (as below). You log onto the OS (Windows 2003 R2 x64 running SnapDrive 6.0.2 or higher in all instances) and get more or less the same Capacity reported as Size (44054560768 vs 44054599680) but what the OS sees as used (13928558592) is nothing like what GetNaLun is putting out (44134756352).

We can't narrow this down to a specific ONTAP rev as it appears to be happening across a mix (7.3.2 & 7.3.5.1) or LUN multiprotocol types (windows & windows_gpt). We have noted that it  appears to happen on our 6070 controllers as opposed to our 3020s but that could be an irrelevancy as we have relatively few (and low-end) iSCSI LUNs running on the 3020s.

I'm less a dedicated storage engineer than a sysadmin who scripts a bit so if I've missed a something totally fundamental to the way ONTAP calculates these blocks, please feel free to give me the WAFL-for-dummies

PS C:\> Get-NaLun /vol/HRDB/hrdb.lun | fl

BackingSnapshot           :
BlockSize                 : 512
CloneBackingSnapshot      :
DeviceId                  :
IsSpaceReservationEnabled : True
Mapped                    : True
MultiprotocolType         : windows
Online                    : True
Path                      : /vol/HRDB/hrdb.lun
ReadOnly                  : False
SerialNumber              : HnUAT4JS77Ww
ShareState                : none
Size                      : 44054599680
SizeUsed                  : 44134756352
Staging                   : False
Uuid                      : 4cb34210-4d01-11dd-aaa6-00a09805bb72
DeviceIdSpecified         : False
Comment                   :

[timothyn · Accepted solution]

What the toolkit is returning should be the same as the "Occupied Size" if you run "lun show -v" on the controller.  But they are both going to be very different than what the host OS sees in many cases.   The storage controller can only keep track of blocks that have been written because the OS won't (usually) free unused blocks.  If you write a 1GB file in Windows and then delete it, ONTAP doesn't know that those blocks are no longer in use until the OS tries to rewrite over that data.  So if you have a lot of changing data on a LUN, it will probably be completely "occupied".

This thread has a little more information:

http://communities.netapp.com/message/30639#30639

Edit:

By the way, you can use the Get-WmiObject Cmdlet to ask the Windows hosts how much free space they have on each disk:

PS C:\> Get-WmiObject -ComputerName WSFCRRE2 Win32_LogicalDisk
DeviceID     : C:
DriveType    : 3
ProviderName :
FreeSpace    : 1021333504
Size         : 13849587712
VolumeName   :

DeviceID     : E:
DriveType    : 3
ProviderName :
FreeSpace    : 5512118272
Size         : 5581565952
VolumeName   : New Volume

Those won't match exactly with LUNs because you can have multiple volumes per LUN or even one dynamic volume spread across multiple LUNs, but it might be the info you are looking for.

[tom_maher]

Thanks Eric - that makes perfect sense - we'll go with what the client OS sees.