- Newest
- Most votes
- Most comments
Hello,
Thank you for writing to us.
I believe you have created an iSCSI LUN [1] of 16TB from an ONTAP Filesystem of 16TB storage capacity.
Upon mounting this LUN to windows OS, it will be presented to the initiator as a Disk with some overhead to the disk configuration, then filesystem headers once it is initialized and further the partition headers once volume is created. Then you would be writing data to the volume. iSCSI Client or initiator could only have view & control up to this level, and not the savings at volume or aggregate level from where LUN was created.
For iSCSI server side usage and available space iSCSI Target or ONTAP file system need to be referred. For the usage and free space at AWS FSx Ontap file system level we have cloudwatch metrics [2] [3]. Also you may use Ontap CLI for space utilization [4].
Hence it is not possible for the Client side OS to view the free space at SSD File System or LUN back end level.
[1] https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/create-iscsi-lun.html [2] https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/file-system-metrics.html [3] https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/monitor-fs-storage.html [4] https://docs.netapp.com/us-en/ontap/volumes/commands-display-space-usage-reference.html
Understanding LUN space reporting with FSx for ONTAP thin provisioning
This is a fundamental difference between how ONTAP manages storage (thin provisioning + deduplication + compression + tiering) and how Windows sees a block device (LUN = fixed size disk).
Why Windows shows less free space
Windows sees the LUN as a fixed-size block device. It reports free space based on:
- LUN size (16 TB in your case) minus data written to the filesystem (9 TB) = 7 TB free
Windows has no visibility into ONTAP's backend storage efficiency (dedup, compression, tiering). The OS only knows the logical LUN size.
Options to expose more space to Windows
Option 1: Thin-provisioned LUN with overcommitment (recommended)
Create the LUN larger than the physical volume, relying on ONTAP's space efficiency:
# Example: 32 TB LUN on a 16 TB volume (2x overcommit)
lun resize -vserver <SVM> -path /vol/<volume>/<lun> -size 32TB
# Enable thin provisioning on the LUN
lun modify -vserver <SVM> -path /vol/<volume>/<lun> -space-allocation enabled
After resizing the LUN, extend the volume in Windows:
- Disk Management > right-click the volume > Extend Volume
Risk: If actual data exceeds physical capacity, the volume goes offline. Monitor with CloudWatch StorageUsed metrics and set alarms.
Option 2: Enable SCSI space reclamation (UNMAP/TRIM)
This allows Windows to return deleted blocks to ONTAP, improving space efficiency reporting:
# Enable space allocation on the LUN (enables SCSI UNMAP)
lun modify -vserver <SVM> -path /vol/<volume>/<lun> -space-allocation enabled
# Verify
lun show -vserver <SVM> -path /vol/<volume>/<lun> -fields space-allocation
On Windows, ensure TRIM is enabled:
fsutil behavior query DisableDeleteNotify # Should show: DisableDeleteNotify = 0 (TRIM enabled)
Option 3: Monitor from ONTAP side
Use ONTAP CLI to see the real storage efficiency:
# Volume space with efficiency savings
volume show -vserver <SVM> -volume <vol> -fields size,used,available,percent-used,dedupe-space-saved,compression-space-saved
# LUN space usage
lun show -vserver <SVM> -fields size,used,mapped
Or use CloudWatch metrics:
StorageUsed— actual physical storage consumedStorageCapacity— total provisioned capacity
Best practice for iSCSI LUNs on FSx ONTAP
- Enable thin provisioning on both volume and LUN
- Enable space-allocation (SCSI UNMAP) on the LUN
- Set volume autosize to grow automatically:
volume autosize -vserver <SVM> -volume <vol> -mode grow -maximum-size 20TB - Set CloudWatch alarms on
StorageUsedpercentage to prevent out-of-space conditions - Consider LUN overcommitment (e.g., 2x) if your data reduction ratio is consistently high
References
answered a month ago
Relevant content
asked 3 years ago
asked a year ago
- AWS OFFICIALUpdated 2 years ago
