nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Find more posts tagged with

Accepted answers

CHRISMAKI

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.

All comments

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.

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%2525

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.

CHRISMAKI

Steve_A

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