Data ONTAP Storage Management Questions for Volumes containing LUNs

[jmmorrell]

1. Why is it recommended to make the snap reserve 0 on a volume containing a LUN? I thought you would want some snap reserve if you're going to take snapshots?
   
   1. Source: http://now.netapp.com/NOW/knowledge/docs/ontap/rel733/html/ontap/bsag/GUID-A79CC460-E4B9-45B5-A702-FB888498D1A2.html
      
2. Why does Data ONTAP require the volume option "create ucode" on for a volume or qtree path containing a LUN? Does Data ONTAP turn this on automatically when you create the LUN inside the volume?
   
   1. Source: http://now.netapp.com/NOW/knowledge/docs/ontap/rel733/html/ontap/bsag/GUID-D1389AED-4E85-42AB-BC18-6EE323802515.html
      
3. What is the difference between "vol options vol_name try_first snap_delete" & using the "snap autodelete" settings: snap autodelete <vol-name> commitment disrupt, snap autodelete <vol-name> trigger volume, snap autodelete <vol-name> target_free_space 10, snap autodelete <vol-name> delete_order oldest_first, snap autodelete <vol-name> defer_delete none, snap autodelete <vol-name> on
   

[adamfox · Accepted solution]

SnapReserve exists for one real reason...and it's entirely based on NAS concepts.  When space is deleted, users (and administrators) like to see free space show up.  All volume snapshots live in the volume with the Data in ONTAP regardless of the reserve settings.  What is useful for NAS volumes is to set aside space ahead of time and then when blocks are deleted from the active filesystem, you simply account for those blocks in the reserve space (no data is actually moved) and thus "free" space in the volume.  This makes the percentages look right.  In a SAN context, this makes little sense because the "free space" seen by the user is inside the LUN, not in the volume itself.  The SAN host has no concept of a volume or the space it consumes.  So why set aside space for an effect you won't get anyway?  Just set snap reserve to 0 and manage the volume as one large hunk of space with active LUN blocks as well as snapshot blocks.  The autogrow and autodelete policy engines can help you manage the flexvol space.

I'm not sure why they want Unicode set, but they do so I do it.  In a LUN volume, there's no good reason not to do it, but I'm not sure of the technical reason why Eng wants it.

The vol option tells ONTAP which policy (autogrow or autodelete) to do first.  This allows these two space management policies to work in tandem.  Most folks I've worked with grow first, then delete snapshots, but there may be local reasons why one would switch this up.  The snap delete settings tell the autodelete policy what kinds of snapshots are eligable for deletion.  Perhaps you have a snapmirror baseline on a really slow link that would take weeks to re-initialize.  Maybe you don't want autodelete to touch that one.  Maybe space is all that matters and you can easily recreate your baseline.   It also allows you to decide the order in which snapshots are deleted.  Again, this would be a local decision based on the usage of the data as well as retention policies, etc.

Hope this helps

[jmmorrell]

This was very helpful. Thanks. Do you have an example of the snapshot autodelete settings needed to not delete a snapmirror snapshot but still keep the LUN from going offline?

[adamfox]

Not sure about this and will defer to any subject matter experts out there, but as I see it, if you are willing to keep any snapshot around, and you don't grow, there's a chance (probably not very large, but a chance) that you will run out of space.  It all depends on the change rate in the volume.  In this case, monitoring your space is your friend.  In the vast majority of cases, you'll be fine.

Note:  This is not a NetApp-specific issue.  Any SAN vendor who supports snapshots has to deal with this same issue.  For the truly paranoid, ONTAP does offer space reservations for LUNs to act as a last resort space to write new data.  Most customers choose not to use this as it's not very efficient (worst case you would reserve the entire LUN space which kills efficiency) and choose rather to put the policies in place, then get some kind of notification (using Operations Manager or some custom scripts) when space gets tight to allow storage admins to address the situation manually if needed.

[jmmorrell]

Another question about the "create ucode" option. When would you NOT want to use it on a NAS volume? I read to not enable on a volume containing more than 50,000 files. I would love to know what benefit it has just so I can explain to customers what it does exactly.

[aborzenkov]

As far as I can tell, you do not need it in NFS-only environment – if volumes will never be accessed by CIFS clients.

Hmm ... another thread raised question about NFSv4 and UTF-8. I could not find any clear explanation whether NFSv4 is using the same convert-to-unicode mechanism as CIFS is; probably yes. So you may need it even in NFS-only for NFSv4; but would be nice if someone from NetApp clarified it.

Message was edited by: aborzenkov

[jmmorrell]

Is it safe to turn on "create ucode" on vol0?