0

As I got a NetApp that was configured by somebody else I observed that all volumes do have quotas on them and due to this it seems that very often we end-up with problems because someone forgets to update the quota when it does resize a volume.

To be more explicit, these volumes are used by same user so I do not see much logic on having a quota at all.

I do understand the need for a quota when you want to limit how much each user would be able to store, but when I have a single user that is accessing each volume, these seems to be more of an overhead to me.

Please advise when it good/bad to use quotas instead of volume size.

Note: all of these are NFS shares and thin provisioning is not enabled.

sorin
  • 8,016
  • 24
  • 79
  • 103
  • 1
    without quota the user/process can completely fill the volume, what can be bad about that? – HBruijn May 12 '15 at 19:27
  • Is there is a single user accessing the volume, what it would be the difference? Running out of quote or space would make no difference. That's why my impression is that if you have a single user using a single volume, quota is useless. Am I right? – sorin May 12 '15 at 19:29
  • Just to be clear here are few use cases: a backup volume, a volume where you keep build artefacts and where only the build system can write. – sorin May 12 '15 at 19:31
  • With no quota you can fill up all your storage in a few minutes, then you just have to quickly make some clean or buy another storage extention. With quota enabled, you get more capacity planning facilities on your storage space... – krisFR May 12 '15 at 19:38
  • @krisFR each volume has a single export and is used by by a single user, so I do not see how one volume would impact another one. Did I forget to specify that "Thin Provisioning" is DISABLED on all volumes? – sorin May 12 '15 at 19:59
  • 1
    Do you mean you expand the volume step by step, according to the user needs ? Well, in that case i'm quite agree with you, quota seems useless. – krisFR May 12 '15 at 20:05
  • Please make it an answer as it seems that if you do not aim on having different quota per user it does not make sense to have quota at all. – sorin May 12 '15 at 20:24
  • Dedupe and snapshots confuse users on their 'free space' view. Quota to avoid them being confused. – Sobrique May 14 '15 at 11:55

3 Answers3

2

With no quota defined you can fill up all your storage in a few minutes.

The consequence of this would be that you will have to quickly make some clean or buy another storage extention cabinet to extend your available storage.

With quota enabled, you get more capacity planning facilities/better view on your storage space and usage.

By the way, for a single user, if you don't provide him full storage capacities, but increase the volume step by step according to this user needs, i cannot see a reason why quota should be enabled, as increasing the volume step by step will result in the same capacity planning overview and control over your storage.

In other words :

For a single user, increasing volume when it is needed is like granting more quota for a given user when you have several.

In that specific case i would say that enabling quota seems useless to me.

krisFR
  • 13,280
  • 4
  • 36
  • 42
1

If it's all for one user, you can have a user quota instead of a qtree quota. But yeah, quotas are often not required.

Basil
  • 8,851
  • 3
  • 38
  • 73
0

What you should always do is make qtrees as your primary points of storage. That way you can decide to quota - or not. But you can't if they're not qtrees already.

In my environment we generally quota everything, with a limited number of examples because we thin provision and dedupe.

Our key scenarios are:

  • Home drives - we significantly oversubscribe, but give each user a small quota. The odds therefore of enough users filling up space fast enough to knock out the whole systems are very low.
  • project/service based provisions - we present a small (1-3 or so) qtrees, each individually quota-ed. We place these within a volume, which we then thin provision, dedupe and apply a snap reserve. Volume size is set that it could thin provision up to quota size sum + snap reserve size.
  • Intensively deduped volumes, such as VMWare disk images - these we don't quota, because a lot of their use case is the dedupe ratio. We often get 70%+ dedupe, which is good for space and caching.

We also generally snapshot everything - in some cases we snapvault, and in most we auto-delete on the primary.

I would generally suggest that quota-ing is a good thing. The available space (reported) on a volume is always the lowest out of:

  • Free quota
  • free volume space
  • free aggregate space

And note - built into that are snapshots and de duplication.

So we quota, because this minimises confusion - otherwise you can quite easily have the scenario whereby you get confusion between how 'if I delete 1G, why does my free space not change'. It also massively reduces the knock on effect of run away processes/users/logfiles.

The place we don't do it - where we volume provision and high dedupe - the 'view' of those volumes is restricted to admin staff who have a better understanding of how it's working.

Sobrique
  • 3,747
  • 2
  • 15
  • 36