If you’ve worked with Network Appliance storage before, you’re probably already familiar with the idea of snap reserve (storage space set aside to accommodate for Snapshots) and fractional reserve (used with LUNs). I’m going to hold the in-depth discussion of why you need snap reserve and fractional reserve for a different day, but I did want to pass on these commands that were shared with me by a colleague of mine. These Data ONTAP commands, available with Data ONTAP 7.2 or later (some commands are available in Data ONTAP 7.1), will help you manage the space requirements for LUNs on a NetApp storage area network (SAN).
I’ll try to explain the commands along the way, but I would recommend you review the documentation available from the NOW site for more complete information.
vol options <volname> fractional_reserve 0
This command sets the fractional reserve to zero percent, down from the default of 100 percent. Note that fractional reserve only applies to LUNs, not to NAS storage presented via CIFS or NFS.
snap autodelete <volname> trigger snap_reserve
This sets the trigger at which Data ONTAP will begin deleting Snapshots. In this case, Snapshots will start getting deleted when the snap reserve for the volume gets nearly full. The current size of the snap reserve can be viewed for a particular volume with the “snap reserve <volname>” command.
snap autodelete <volname> defer_delete none
This command instructs Data ONTAP not to exhibit any preference in the types of Snapshots that are deleted. Options for this command include “user_created” (delete user-created Snapshot copies last) or “prefix” (Snapshot copies with a specified prefix string).
snap autodelete <volname> target_free_space 10
With this setting in place, Snapshots will be deleted until there is 10% free space in the volume.
snap autodelete <volname> on
Now that the Snapshot autodelete options have been configured, this command will actually turn the functionality on.
vol options <volname> try_first snap_delete
When a FlexVol runs into an issue with space, this option tells Data ONTAP to first try to delete Snapshots in order to free up space. This command works in conjunction with the next command:
vol autosize <volname> on
This enables Data ONTAP to automatically grow the size of a FlexVol if the need arises. This command works hand-in-hand with the previous command; Data ONTAP will first try to delete Snapshots to free up space, then grow the FlexVol according to the autosize configuration options. Between these two options—Snapshot autodelete and volume autogrow—you can reduce the fractional reserve from the default of 100 and still make sure that you don’t run into problems taking Snapshots of your LUNs.
If you have a NOW login, you can get more information on Snapshot autodelete here; more information on volume autogrow is available here. Be aware that SnapDrive may require different settings in order to accommodate its functionality, as it moves LUN management out of the storage system and onto the host. Finally, the values presented here are only examples; be sure to use values that are appropriate for your environment.
Credit for compiling this list goes to my colleague Chauncey Willard. Good work!


5 comments
Comments feed for this article
Trackback link
http://blog.scottlowe.org/2007/12/05/managing-lun-space-requirements-with-netapp-storage/trackback/
Tuesday, December 11, 2007 at 10:26 am
Eric Watkins
Hiya Scott,
Just thought I would give a quick and easy explanation for the fractional reserve (as well as why you need to be careful tuning the fractional reserve setting)
the WAFL file system that Data OnTap uses actually writes a new block for any change. It will not modify the existing blocks. So for example you have a 100gb database in a 110gb lun and you re-index it, every change it makes results in a new block being created. That means you need 100gb of space set aside since the filesystem doesnt modify any blocks.
With that said, you would need 220gb of space in the volume holding the 110gb lun which has the 100gb database in it just to allow you to re-index a database. (lun size + 100% of space for the new blocks to be created). If you want to take snapshots you need to add space beyond that.
You should only reduce the fractional reserve setting is you are ABSOLUTELY sure your changes will never exceed the amount you specify. In other words if you expect you will never change more than 50% of the blocks in a volume you could set the reserve to 50%. Most database applications (such as sql and exchange) require or recommend that you leave the fractional reserve at 100% (to account for upgrades that may re-index the databases, defrags, etc)
Hope that helps
Tuesday, December 11, 2007 at 6:42 pm
slowe
Eric,
Thanks for the explanation. You’re mostly there…
One slight correction: to my understanding, WAFL only allocates new blocks for changes when the existing blocks are locked by a Snapshot. Existing blocks can/may be overwritten if they are not locked by a Snapshot. So, fractional reserve and snap reserve are only required when Snapshots are going to be taken.
The default setting of 100% for fractional reserve ensures that you can take a Snapshot of a LUN and then be guaranteed that you can overwrite every single block in the LUN. To maintain more than one Snapshot, you’d need more than 100% space, hence the extra 20% for snap reserve.
Thanks for the comment!
Monday, December 31, 2007 at 4:37 pm
TimH
One note I’ll add regarding reducing fractional reserve to zero is the requirement for solid management best practices surrounding the storage appliance(s).
It’s all good if the client has a dedicated storage admin, appropriately trained with the tools and time avialable to proactively manage the appliance. This however, is often the weak link for some smaller customer’s whose network admins wear many hats and are likely not to be looking at the thing on a regular basis. In smaller environments I’m inclined to speak with the person who manages SQL or Exchange, explain fractional reservation and let them decide, based on their knowledge of the environment and how well it is managed.
Just a thought…
-Tim-
Monday, December 31, 2007 at 5:06 pm
slowe
Tim,
As with so many other areas of technology, there’s always more to it than just the technology. Being sure that the storage admin is aware of the repercussions of reducing fractional reserve and/or snap reserve is a must in any environment. Thanks for pointing that out!
Take care!
Tuesday, June 10, 2008 at 11:08 am
Gary Taylor
Here’s some more information to help folks understand Snap Reserve and Fractional Reserve when using LUNs in a FlexVol.
Fractional Reserve should be renamed “Space to Protect the LUNs from going offline when writing changes after a snapshot has been taken”
Okay that’s too long but it makes more sense that Fractional Reserve!
You can quite happily work away with 0% Fractioanl Reserve without any issues as long as you have not taken a snapshot the volume.
Also, Snap Reserve becomes a redundant parameter as soon as you create a LUN and change the Fractional Reserve from 100.