Volume and Lun different Size

[rene04]

Hi,

on my Netapp i habe a volume that is 6TB. Available Space is 2,4TB. On this volume i have a LUN with 6TB and it is used 100% (full). No Space left. The LUN is thin-provisioned and mapped RAW to an ESXi VM (Fileserver). How can i get back the free space on my LUN?

regards,

rene

[sgrant]

Hi Rene, hope you are well.

It sounds like ESX is reporting the LUN full but there is actually free space. This could be down to either storage efficiencies that ESX does not understand so cant also report the savings, or deleted blocks in the ESX filesystem that the storage cannot map - so does not delete and just sits there.

Assuming you have space capacity in the aggregate, the easiest thing is to create a new LUN/datastore and Storage vMotion the contents of the full LUN into that one. Then delete the old LUN to release the blocks.

Depending upon your version of ESX (VMware ESX 5.0 and later is supported), when you create the new LUN ensure the space_alloc option is enabled (disabled by default). This will then allow ESX to tell ONTAP which deleted blocks can be recovered from the storage, hopefully to help avoid this situation again. Please see: https://kb.netapp.com/support/s/article/ka21A0000000dLQQAY/what-does-the-lun-option-space-alloc-do?language=en_US

Hope this helps.

Cheers,

Grant.

[rene04]

Hi,

thanks for your answer 🙂

At the moment i am not talking about ESX. Just about OnCommand. I have this bahavior in OnCommand.

regards,

rene

[sgrant]

Hi Rene, is this a continuation of your previous post? http://community.netapp.com/t5/All-Flash-FAS-EF-Series-and-SolidFire-Systems-Discussions/free-Space-in-OnCommand-and-ESXi-different/m-p/134269

Here we discussed that the LUN does not reflect the storage efficiencies seen in the volume (which is why you have free space in the volume). Unfortuantely, while there are blocks available in the volume the LUN will report 100% full. In these situations we need to monitor the volume capacity and the OS filesystem, to make sure they do not run out of space.

If the volume fills then regardless of how much space the LUN thinks it has, it will go offline (unless space_alloc is implemented where it will remain online but read only) and writes will stop.

In your case, assuming ESX also reports it has free space and not full, I wouldn't be too concerned about the LUN being at 100%, since the volume still has space.

Does this help explain for you?

[rene04]

Hi 🙂

no, has nothing todo with the post you mean.

I try to explain a little better 🙂

In OnCommand of my NetApp when i go to Storage -> Volumes i have a volume called x. OnCommand shows me that there is about 2,4TB free from 6TB.

When i now go in the same OnCommand to Storage -> LUNs it shows me for the LUN on that volume that it is 100% used.

Well, i do not want to increase space of that volume because there is 2,4 TB space left and i want to use this space in my LUN.

regards,

rene

[sgrant]

Sorry, that was what I was trying to refer to 🙂

Since the volume has space, and assuming ESX can see that free space i.e. is is not 100% full, then you are safe to ignore the LUN capacity. We have many LUNs that are close to or at 100% full, but since our volumes and file systems have free space there is no problem - the LUN will only run out of space if the volume (or aggregate) is full (assuming the file system is not the reason the LUN is full!)

Since the LUN does not reflect the actual free space available, you need to monitor the OS file systems free space as well as the volume free space only, ignoring the LUN.

Hopefully a clearer answer for you??? Let me know.

[Jiggywalker]

Check out the articles below to see if that helps you. Sounds like you need to use the Space reclaimer

https://library.netapp.com/ecmdocs/ECMP1189419/html/GUID-9D81F3C9-DBD4-4B89-9204-BBFD985696DC.html

https://library.netapp.com/ecmdocs/ECMP1196995/html/GUID-93D78975-6911-4EF5-BA4E-80E64B922D09.html

[rene04]

Hi sgrant,

ok, now we come to the esx free space. this shows me on the host (esxi vm) 5,69 TB in use.

Filesystem D:/

CRIT - 94.9% used (5.69 of 6.00 TB), (warn/crit at 80.00/90.00%), trend: +890.72 MB / 24 hours

Now we have 3 different values 🙂

which one should i believe?

regards,

rene

[sgrant]

If ESX is reporting it is short of space then it needs to be addressed, despite the free space in the volume.

It sounds like the datastore is reserving space, e.g. lazy zeroed thick VMs. In this case the space is reserved in the datastore allowing you to directly manage capacity however those zeros are not written to the storage, so the capacity does not match.

I'm not convinced we have a problem with deleted data not being released on the storage, that space reclaimer would help address, since this would mean we have more space consumed on the storage than the datastore, which isn't the case here. But one definitely to be aware of, also addressed by the use of the space_alloc LUN option that allows the supported OS to tell the storage that the blocks can be safely deleted.

Sound sensible?

[rene04]

Hi,

this is a raw mapped LUN to the OS (Windows Server 2012). The LUN is thin provisioned.

How do i get the space back now?

regards,

rene

[sgrant · Accepted solution]

Hi Rene, in short...the guest will not see any of the storage efficiency savings; you can't claim that space back for the file system to use.

In your thin provisioned environment (both LUN and volume), the storage efficiency savings are at the storage layer only and release blocks back to the aggregate to allow you to create additional volumes/LUNs. The space savings for block based (SAN) storage is on the storage, unlike file based (NAS) storage that passes those savings to the clients. To realise storage efficiency savings directly on the hosts you will need to use NFS datastores.

You will need to increase the size of the RDM LUN on the storage and make that available to the Windows server to expand the file system.

Again, just to point out that since you've thin provisioned both the volume and LUN, you only need to monitor the space of the volume (and aggregate) as well as the file system. You do not need to worry about the LUN itself being 100% full. It is also good practice to regularly run (out of hours) SnapDrive Space Reclaimer (only supported on physical RDMs) or enable the space_alloc feature on the LUN to release those deleted blocks.

Hope this helps.

Thanks,

Grant.

[jm_anglin]

If you have a 6Tb volume with a 6Tb LUN on it but it says the volume has 2.4Tb available, then I suspect you have storage efficiency enabled and it has compressed the LUN.  If someone shrinks the volume (who wouldn't want to reclaim 2.4Tb of unusable space?) and the volume is not configured to autogrow back to at least 6Tb, then you would be in real danger of the LUN going offline as soon as it becomes less compressible (ie: data changes).

[sgrant]

Hello, to confirm, in this case since the volume is thin provisioned the 2.4TB free space is already available in the aggregate - no need to resize the volume to release the space.

As I stated above, you do need to actively monitor the free space in the volume (and aggregate), then you can ensure the volume has enough space to prevent the LUN going offline. Obviously, also not forgetting to also monitor the space on the host file system.

Thanks,

Grant.

[rene04]

Hi all,

many thx, i understand now 😉

regards,

rene