Space Reservation on a LUN

[TMADOCTHOMAS]

I have space reservation disabled on a few LUNs and noticed some strange behavior. As an example, I have a 12TB LUN with 2.2TB of free space, with space reservations disabled. It is on a 13TB volume which currently shows 3.01TB free. The volume is thin provisioned.

If I uncheck the Space Reservation box in System Manager to enable space reservation, I would expect used space to increase in the volume and aggregate, however it only increases in the volume! The volume shows ~790GB free as opposed to 3.01TB since the 2.2TB of LUN free space is now taking up room. However, I don't see a drop of 2.2TB in free space in the aggregate. Why is that? Any ideas?

[Ontapforrum · Accepted solution]

Hi,

The thick and think combination terminology of vol and lun can be very tricky and has been a matter of confusion historically. Therefore, NetApp has recommendations when it comes to this combination.

Thick LUN behind Thin vol has no bearing on the containing aggregate. Which means when you "enable space reservation" on LUN, it only logically drops space from the volume (Book keeping),  however the containing aggregate has no effect b'cos the underlying VOL is thin. The only time you will see drop in aggregate space is when you actually write to the lun. 

Note: The writes to LUN (even with space-reserved) are actually not guaranteed (write operations can fail if containing aggr runs out of space).

In such scenarios, keeping an eye on the vol is futile, rather you should enable Autogrow for the volume and set the maximum size for the volume to the size of the aggregate. In this configuration, you just need to "keep an eye on the target aggregate free space actively", but you do not need to monitor the free space in the volume.

Reference for recommendations:
https://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.dot-cm-vsmg%2FGUID-2F5C9474-FFE9-4E59-84DB-1B9D6D134688.html

Thanks!

[TMADOCTHOMAS]

Thank you @Ontapforrum that is an immensely helpful answer. Effectively, it sounds like it makes no difference what the LUN setting to the aggregate if the volume is thin (all of our volumes are thin). If I make the LUN thick, the volume appears fuller but there's no practical effect except that the volume might alert due to low space. I can see an advantage in making LUNs thick so I don't inadvertently set the volume size too low.

We typically set the autogrow limit to 20% of the volume size. I actually have my OCUM volume alerts configured based on this assumption (I set them to 68% warning and 76% error which equates to 82% and 92% - OCUM inexplicably alerts based on potential volume size via autogrow vs. actual current volume size). What are the implications of changing the upper limit to the aggregate size? We aren't "living on the edge" but isn't there a risk of a volume rapidly filling up due to some out of control process and filling up an aggregate? Would love to hear any additional thoughts on this!