Lun Reclaim from unix end and yet at storage end it does not show released size

[backupstorage]

Hi team, 

We are in process of reclaiming space from linux server and ran the command of fstrim also but at the storage end it does not show same space reclaimed. 

Anything from storage to check or scan to have relase space from storage end 

Regards, 

[pedro_rocha]

Hi,

Is it a LUN or NFS mount?

fstrim did any reclamation or none at all?

fstrim -v gives the potential reclaimable data?

is the volume/lun THIN?

Regards,

Pedro.

[Ontapforrum]

Two things:

1st - You didn't mention which *nix, KB here.

https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/What_are_the_recommendations_for_the_host_stacks_supporting_SCSI_UNMAP...

2nd - In any case, If the Host OS TRIM is manually done, then ensure this option is enabled.

-space-allocation enabled (This option enables ONTAP to reclaim space automatically when your host deletes data. It is set to disabled by default.)

Steps here: (You need to follow the exact steps)

https://docs.netapp.com/us-en/ontap/san-admin/enable-space-allocation-scsi-thin-provisioned-luns-task.html

[backupstorage]

@pedro_rocha @Ontapforrum  Thank you for reply 

 volume/lun THIN? Yes it is Thin provisioned 

reclaim space automatically is enabled already 

fstrim  -->it didn't help much there is difference of 200 GB 

Please help to know if anything has to be done on it. 

[pedro_rocha]

is it a LUN (iSCSI / FC) or volume (NFS)?

as @Ontapforrum said, if LUN, -space-allocation was enabled after it was presented to the host? If yes you should rescan

which file system are you using if LUN?

did you review this? https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/Storage_auto-reclamation_does_not_occur

[backupstorage]

@pedro_rocha  Will check and get back to you accordingly 

[backupstorage]

@pedro_rocha 

which file system are you using if LUN? Lun is ISCI

yes we did review the above KB and space-allocation enabled  is already set 

Let me know if below rescanning is required to be done 

PS Link Refer

https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/How_to_rescan_and_recover_LUN_paths_in_a_host_after_modifying_SLM_repo...

Linux hosts:

• Rescan after add-reporting-nodes.
  1. Starting RHEL 6.5 & RHEL 7.0 onwards, run the following command to update active/optimized paths after add-reporting-nodes:
     # /usr/bin/rescan-scsi-bus.sh –a
  2. For RHEL 5 and RHEL 6.4 (including previous updates), run the following command to update active/optimized paths after add-reporting-nodes:
     # /usr/bin/rescan-scsi-bus.sh
     Note: Nothing additional has to be done in the multipath layer.
• Rescan after remove-reporting-nodes
  1. Separate rescan steps are required for SCSI layer and Multipathing layer in Linux storage stack to clean up stale disk paths after remove-reporting-nodes in SLM.
  2. Run the following command to remove stale LUN paths in SCSI layer
     # /usr/bin/rescan-scsi-bus.sh –r
  3. Next run the following command to remove stale LUN paths in multipath layer:
     # multipath -r
     Note: The /usr/bin/rescan-scsi-bus.sh script is available as part of the native sg3_utils package.

Anything from the storage end scan can be done ?

Scanning on storage end will it require reboot ?

If Scanning is possible on storage end , is it disruptive operation?

Thanks in advance 

[pedro_rocha · Accepted solution]

Hi,

rescan is required if the LUN has been changed space-allocation from disabled to enabled

it should not pose any downtime to rescan

you can do any kind of rescan from the storage side

you should run fstrim to reclaim the space after all