Lun Free space reclaim

[adi_213]

Environment: NetApp FAS and Linux Suse

Desc: Added 100gb to an exisitng 100gb lun, but at server end this new 100gb is still not taken over.

Lun size: 200GB

Used size 70GB

Normally Shrinking a lun requires data migration to a new resized LUN, but if we already know the new blocks are free, and we need to say reclain 90GB out of the new unused 100GB - Is it possible to do it directly on netApp?

What will netapp reclaim first - the empty blocks of the lun (seeing from netapp perspective as it only shows 70GB in use 130gb free)?

[Ontapforrum]

On this question - Added 100gb to an existing 100gb lun, but at server end this new 100gb is still not taken over.

Ans: Have you run host side resize utility to extend the filesystem ? LUN re-size is a 2 step process, first step is re-sizing the LUN (RAW) from the storage side and second step is to re-size the partition/filesystem from the HOST side. Extending the LUN from storage side alone will not automatically re-size the HOST side partition/filesystem.

This KB has steps:
https://www.suse.com/support/kb/doc/?id=000016035

On this question - we need to say reclaim 90GB out of the new unused 100GB.
Ans: Is this not a THIN LUN ? If it is then, only the logical space is reported/consumed, physical space is not consumed.

On this question - Is it possible to do it directly on netapp?
Ans: Yes you can shrink LUN on netapp side but that might currupt the data on the Host filesystem. NetApp has no idea about the blocks on the HOST Side filesystem, for it everything is read/write IOPS. In order for NetApp to be notified about the FREE blocks reported by the Host filesystem, it must be done through SCSI UNMAP (space reclaimer process) supported by the Host OS.

On this question - What will netapp reclaim first - the empty blocks of the lun (seeing from netapp perspective as it only shows 70GB in use 130gb free)?
Ans: It doesn't matter, it's just logical space reservation. Please see the guidelines to be followed while shrinking LUNs?
https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/What_are_the_guidelines_to_be_followed_while_shrinking_LUNs%3F

[adi_213]

Thanks for the inputs.

1. Space was added accidentally - So on purpose we did not perform pv resize.

2. Yes this is thin, and netApp is only showing 71gb / 200gb used., since this is linux, i don't think it will support SCSI THIN Provisioning like MS Windows

3.  I know due to server controlling the FS blocks netapp is not aware about the block usage and can truncate the data.

The articles that you have shared or i have read are mostly for decreasing an existing size LUN (if 100gb then even on server PV , VG are of 100gb)

In my case - on server the PV and VG still does not have the control of the new blocks since they have not been increased.

My thoughts : If i start reclaiming the free space (space unallocated on server) - will netApp able to understand or prioritize the empty block - (here by empty i do not mean server written and then flagged for over write blocks, i mean the blocks that server has not picked up yet which it does in pv resize procedure)

Ref: There was a case study where a team increased MBR drive lun on windows to 2.5TB (MBR will not support over 2TB), since the blocks were not in use, they reclaimed them without any impact to FS.

Wondering it that procedure was correct or just a fluke

[Ontapforrum]

I don't agree to this statement : Since this is linux, i don't think it will support SCSI THIN Provisioning like MS Windows.
Ans: That's incorrect understanding especially if you say 'linux', I have been using RHEL with thin-provisioning for some years now.  To be honest, In the current technological space, when storage efficiency has become so much important that the primary value of the any OS being aware of the underlying storage being THIN is that the OS can inform the storage-subsystem to return blocks to its free pool when the OS no longer has data on those blocks.  Number of OS vendors these days adhere to standardized T10 SCSI command set, as part of the plugin that allows this kind of lower-level communications between the OS and the storage.

Storage doesn't really care whether you are creating filesystem on a raw partition or implementing Logical Volume Management (PV/GV/LV) etc. upper later space management falls on to the Host side.

I am not familiar with SUSE variant of linux and Build/version you have, but I found this googling.

https://documentation.suse.com/sles/12-SP4/pdf/stor-admin_color_en.pdf

1.11.2 Freeing Unused File System Blocks
On solid-state drives (SSDs) and thinly provisioned volumes it is useful to trim blocks not in use
by the file system. SUSE Linux Enterprise Server fully supports unmap or trim operations on
all file systems supporting these methods.

The recommended way to trim a supported file system (except Btrfs) on SUSE Linux Enterprise
Server is to run /sbin/wiper.sh

My thoughts : If i start reclaiming the free space (space unallocated on server) - will netapp able to understand or prioritize the empty block?
Ans: No, and even if we consider that the THIN is not supported (Due to lack of UNMAP capability in your variant of SUSE), there is no way to prioritize the empty blocks from NetApp storage side.

Regarding the ref: It's quite vague to be honest, and b'cos I haven't read that case study, it's not fair for me to comment.