3

We have one volume in our NetApp filer with multiple Qtrees that are shared as CIFS. To resize a share we normally:

  1. Modify the quota on the share
  2. Use "resize" command on the volume

Perhaps I'm missing something but why would we need to "resize" the volume? Changing the quota shouldn't change the size of the volume. Perhaps there's other internals that I do not grasp.

1 Answer 1

5

quota resize (or the equivalent action in one of the GUIs) forces the quota service to scan the volume and apply any changes made to /etc/quotas. It's not actually resizing your volume. Until you execute a quota resize (or alternatively disable and reenable the quota service), no changes made to the quota definitions will be applied. Also notable: during the time it takes to perform that scan you kicked off with your resize, quotas will not be enforced. This is a good reason to use individual volumes for network shares instead of qtrees.

Another good reason to use volumes instead of qtrees is that, depending on how you back this data up, it can take a good deal longer to back up a single 10TB volume containing 10 1TB qtrees than it would to back up 10 1TB volumes.

I don't know about you guys, but the reason we went with qtrees inside volumes was so we could overprovision shares without having to overprovision the aggregate. A failure to keep adequate space in the CIFS volume wouldn't cause other volumes to die, like a failure to keep adequate space in an aggregate would.

If you need to put someone to sleep or want a good reference for the quota command line, check this out.

1
  • Thank you for the great explanation and the source link! Jun 5, 2014 at 21:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .