A thick LUN has filled up, and this caused it to go offline. It's a VM VHD file LUN. We managed to brink it back online and delete some data from the LUN from within Window, but it keeps going offline due to lack of space.
How can I make it aware that we've just deleted 80GB of data so it doesn't keep going offline? We've just upgraded our hosts to Server 2012 R2 and we haven't yet installed SnapDrive and apparently we're not authorised to download it from the NetApp site now.
Can we do the space reclamation thing without SnapDrive?
We have FAS2020 with 7.3.2 OS.
4 REPLIES 4
Thank you for contacting NetApp communities,
My Experience :- If you delete a load of data from the client-side (eg NTFS) the client marks the blocks as free, as opposed to physically zero'ing out the data, right? Down at the storage level WAFL has no way to know these blocks have been deleted, so when you write more data to the LUN it will consume new blocks in the volume. Typically, as a LUN ages, you will find the NetApp side will show the LUN at, or close to 100% full, but the clients filesystem may still have plenty of space. This is by design, and often not a problem - although it looks a bit odd at first. Check out Snapdrive's Space Reclaimer feature if using Windows - this will reclaim those free blocks at the WAFL end if required.
As i see you are using 7.3.2 where the space relclamation is only possible using SNAPDRIVE. Please refer the KB below which shows how to reclaim space from LUN without SnapDrive but articles refers to Ontap Version 8.1.2 which mean you need to upgrade least to this version to make use.
Reference :- How to Reclaim LUN space Without SnapDrive
Note:-If you don't want have luxury of downtime as above KB needs to have downtime to reclaim space. I would suggest upgrading to Ontap 8.2 which supports AUTO RECLAMATION. Where once you enable auto reclamation on a LUN whenever there are blocks freed up at the host side NetApp will automaticlly reclaim the space marking the blocks as free at the controller side.
I have managed to rejig volume space to allow me to increase the LUN so it now seems to stay online.
If I shrink the partition in Windows, then shrink the LUN, then increase the LUN back and grow the partition in Windows back, will that make the NetApp realise the data is not really 700GB, but actually 620GB.
Not sure how you are getting on with this, however I am not convinced that resizing a partion without SnapDrive is a good idea. There is no connection between the partion and LUN sitting on the storage without SnapDrive and you cannot therefore guarantee the blocks will align when you perform the resize, i.e. you may lose data! In addition, the storage will not release those blocks since again there is no connection between what Windows sees and the blocks on the NetApp storage. As mentioned already, NetApp does not know which are in-use blocks or blocks that Windows has released/deleted.
As I understand it, the only reason a thick LUN will run out of space is if the volume fills - unless of course the actual filesystem ontop of the thick LUN is full. You need to ensure there is free space in the hosting volume/aggregate. Yo may already be aware but if your volume has guarantee set to "volume", i.e. also thick provisioned, you have fractional_reserve set to anything other than 0% and have at least one snapshot in the volume, then you could reclaim back some space by setting fractional_reserve to 0% - however with the normal caveats (https://library.netapp.com/ecm/ecm_download_file/ECMM1278361 - page 33)
The auto reclaimation referred to is the space_alloc option that becomes available in Data ONTAP 8.2 and is valid for Windows 2012, see: https://library.netapp.com/ecmdocs/ECMP1368845/html/GUID-93D78975-6911-4EF5-BA4E-80E64B922D09.html
However, without upgrading ONTAP and no SnapDrive, the only other option I can think of to release those filesystem deleted blocks, is for you to create a fresh new LUN and copy the files (at the file system level, e.g. xcopy or ndmp) into that new LUN. If you do anything at the block level, then those released/deleted blocks will also follow. The new LUN used size will then match the filesystem size. Although, you will again eventually end up in the same situation as files are deleted/overwritten in the filesystem, without space_alloc or SnapDrive to clean this up.
Hope this help,