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.