We're using the toolkit (188.8.131.52) 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 & 184.108.40.206) 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
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".