Thick provisioned volume available space much less than sum of LUNS

[zamo2k]

Hello,

I know this is probably something recurring, but I searched for a way to troubleshoot it and can't really find something like my case.

I have a thick provisioned volume of 25TB, containing some thick provisioned LUNs, no dedup nor snapshots (neither at LUN nor volume level).

The sum of the space covered by LUNs is about 12TB, but the volume shows less than 600GB available.

I tried some commands and it seems that the remaining space is "reserved" but not available...and I can't understand why.

Can you please help me troubleshooting this situation? How can I recover the missing 12TB?

Thank you in advance!

Little prologue: on the same aggregate there was a volume where dedup was ON and its temporary files probably grew over the total amount of space of the aggregate. This locked two thin provisioned LUNs within the 25TB volume. So I resized these LUNs, and made them thick.

Some command outputs:

::> volume show-space -volume vol_recorders_win_08

Vserver : svm_win
Volume : vol_recorders_win_08

Feature Used Used%
-------------------------------- ---------- ------
User Data 24.34TB 97%
Filesystem Metadata 4.88GB 0%
Inodes 52KB 0%
Performance Metadata 28.21GB 0%

Total Used 24.37TB 97%

Total Physical Used 12.09TB 48%

::> volume show-footprint -volume vol_recorders_win_08

Vserver : svm_win
Volume : vol_recorders_win_08

Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 12.09TB 40%
Volume Guarantee 12.65TB 41%
Flexible Volume Metadata 142.2GB 0%
Delayed Frees 267.2GB 1%
File Operation Metadata 4KB 0%

Total Footprint 25.14TB 82%

::> df -r -g -aggregate aggr_data_08
Filesystem total used avail reserved Mounted on Vserver
/vol/vol_backup_vms_08/ 1288GB 0GB 1288GB 0GB /vol_backup_vms_08 backup_vms
/vol/vol_backup_vms_08/.snapshot 227GB 0GB 227GB 0GB /vol_backup_vms_08/.snapshot backup_vms
/vol/vol_recorders_win_08/ 25600GB 25037GB 562GB 12350GB --- svm_win
/vol/vol_recorders_win_08/.snapshot 0GB 0GB 0GB 0GB --- svm_win
/vol/vmcluster_ctn_nfs_data_08/ 3793GB 1574GB 2219GB 0GB /vmcluster_ctn_nfs_data_08 vmcluster-ctn_vms
/vol/vmcluster_ctn_nfs_data_08/.snapshot 199GB 411GB 0GB 0GB /vmcluster_ctn_nfs_data_08/.snapshot vmcluster-ctn_vms

[aladd]

Do you have space reservation enabled for this environment?

https://docs.netapp.com/us-en/ontap-sm-classic/online-help-96-97/concept_using_space_reservation_for_luns.html

You may also check the snap reserve for the volume.

[zamo2k]

As said, both volume and LUNs are thick provisioned:

The df command above shows that the volume has no snapshot reserve. Snapshots are disabled for volume and LUNs.

/vol/vol_recorders_win_08/.snapshot 0GB 0GB 0GB 0GB --- svm_win

So I can't understand why half of the volume is not available.

Thanks.

[aladd]

Please see the link concerning space reserved LUNs,

While we're reviewing that piece it would also be a good idea to check fractional reserve settings.

[NetApp_SR · Accepted solution]

I agree with aladd, fractional reserve sounds like it may be the culprit. Please reference the below links.

What are the space requirements for LUNs with volumes that have 100% fractional reserve?
https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Systems/FlexPod_with_Infrastructure_Automation/What_are_the_space_requirements_for_LUNs_...

Fractional reserve is being allocated even though no snapshots exist
https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/Fractional_reserve_is_being_allocated_even_though_no_snapshots_exist

LUN offline due to the fractional reserve 100% setup
https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/The_LUN_offline_due_to_the_fractional_reserve_10025_setup

[zamo2k]

That was the issue!

Many thanks in advance!

As soon as I set fractional reserve to 0 on the volume, the expected available space came back. I don't get why the setting "fractional reserve = 100%" is the default when using both volume and LUNs with thick provisioning, but that's it.

Many thanks again! Also to @aladd !

Regards