Any way for Windows OS to see actual free space left on a LUN?

[Steve_A]

Example
• 16TB raw storage (SSD)
• 15TB volume thin provisioned on raw storage
• 15TB iSCSI LUN thin provisioned on volume above.

15TB volume presented to Window Server and 9TB of data saved to it.  OS sees 6TB free. So far, so good.

On the back end, data footprint is reduce from 9TB  to 7TB with 8TB free on aggregate and the Volume.  Data reduction is great but not sure how to take advantage of it in Windows?  I would like to avoid guessing at making the LUN ~20% larger to take advantage of the back end free space because dedupe and compression is a moving target.  It would be better if the OS was aware of the actual free space available on the volume and could consume a larger percentage of the volume as data reduction permits.    The built in Windows dedupe has this feature as shown below - it understands total size and 'size on disk'. 

We are not using Windows dedupe in combination with a NetApp LUN.  Just showing this as an example of how I would like to see the Netapp data reduction in Windows.

[elementx]

> The built in Windows dedupe has this feature as shown below - it understands total size and 'size on disk'. 

Well, the utility can't know the size on another system's disk without using the said system's API or CLI to figure it out...

I suppose you could use scripts or write a custom UI or Web tool that would gather these details from both Windows and ONTAP and show them similarly to the way Windows does for disks it controls.

If I understand the question correctly, there's no harm in having extra space given to the LUN. It's empty and doesn't consume any capacity as long as UMAP/TRIM is on (which it is by default in newer versions of Windows).

[Steve_A]

In our case it is one aggregate and one LUN (ONTAP in AWS).  It would be nice for the OS to see all the free space on the volume and be able to use it with the LUN.  Windows is aware that it is a thin provisioned disk in properties but again, there doesn't seem to be anything useful to do with this information or the data reduction capability in the situation I described.   Manually oversizing the LUN and hoping dedupe keeps you from exceeding your raw capacity seems like a 20 years ago solution.

[AlexDawson]

Hi Steve,

Windows is aware it is a thin LUN so that it can know to send UNMAP/TRIM commands when blocks are freed up in the NTFS on top of it.

Taking a step back, I'm not really sure what problem you're trying to solve here? If you have a single LUN in a single volume and snapshots turned off.. there is no need for the OS to know about the underlaying geometry, since it's never going to exceed the allocated size. You would manage the free space on your SAN (assuming multiple workloads) in a seperate measure to Windows. And if it's a single workload, what's the worry?

If seeing actual physical free space after dedupe is a requirement, maybe using SMB instead of mapping a LUN might be a better choice.

[Steve_A]

It's being used for windows SQL databases.  The databases are often sparse and the data reduction is pretty effective so we never utilize more than 40% of the underlying raw san storage.  The only way to do so now is to make the LUN 2x the size of the underlying raw storage which is a bit risky, even with monitoring.  In this way I'd rather have the OS report real free space than than get an email in the middle of the night that the SSD's are 98% full.   Expanding the underlying SSD's is not an immediate option in our case.

[AlexDawson]

Ok, for SQL we would almost always suggest LUNs (although with SMB3, it is a valid option..)

What would you do with the knowledge of how much space is "free" in the aggregare though? You mention a 9TB data size, on a 16TB LUN.. and wanting to see that space so it can be used for other purposes.. but that will also fill the aggregate up. 

To me I'm guessing you're looking for a scenario where you make 2 x 16TB LUNs, and put 9TB data in one and 6TB data in the other.. my take would be, why not just make them 9 and 6TB LUNs respectively? Or put all the data in the 16TB LUN?

 At the end of the day, this is a mostly academic question - as far as I'm aware, the iSCSI and SCSI/FC specification don't include any method to inform the attached initiators of underlaying geometry data including blocks available/free.

[Steve_A]

The DBA's can manage the workflow queues to keep the data volume from becoming full if they knew the actual free space (in the case that a LUN was over provisioned on purpose).  If the workload got too backed up then of course we would expand the SSD pool after a time, but we've not yet found a way to utilize more than 40% of the existing SSD pool without over provisioning the LUN.  Right now it is 1x 15TB thin LUN on 15TB thin volume with 16TB of raw disk.  It's probably safe to make the LUN 30TB based on the average 60% data reduction rate, but was hoping there was a better solution.

I suppose someone with the skills could make a script that polls the SAN for free raw space and then resizes the LUN and then the Windows volume once a day.  I'm laughing as I write this as it sounds like a terrible idea even if you could get it to work.

[Steve_A]

This article is interesting because the problem they are discussing is what I wish would happen in my implementation. Aggregate runs out of space so windows disk reports actual free space

https://kb.netapp.com/?title=onprem%2Fontap%2Fos%2FWindows_client_still_displays_insufficient_space_even_though_the_volume_capacity_does_not_reach_100...

[CHRISMAKI · Accepted solution]

I don't actually believe this is possible because the LUN itself never recognizes the space savings. Efficiencies are only applied at the volume and aggregate levels, not the LUN which is technically a file on a volume. You can however over-provision the LUN and Enable Space Allocation which will allow ONTAP to notify the host when the hosting volume is full. Alternatively, you could provision either a CIFS Share or NFS Export instead which you could then allow Windows to see the true available space. 

[Steve_A]

Thanks for the information. Though not ideal, I think this might be as close as we can get.