It is commonly recommended that one shouldn't fill a ZFS volume beyond 70-80% to prevent fragmentation. I, however, find that I have gone beyond that in the past (the "I need just a bit more, I'll clear it later"-syndrome). I'll soon migrate some of my volumes to new ones so they are 'clean' again, and would like to enforce a limit on said volumes. Essentially an all-user quota to prevent me from ever crossing that barrier.

So, is it as simple as just setting the following (assuming a 3TB disk in this case)?

zfs set quota=2000G storage/data

If so, is it possible to use a percentage here instead?

Finally, given larger volumes, is the recommendation still 70-80%, or should one calculate a more reasonable amount by multiplying the largest possible file to be stored/copied on it times an x amount (much like one would not set monitoring to throw a critical alert on 90% of a 10EB volume but would calculate average data-growth and set something more realistic instead)?

I guess I can discover the first to questions with some googling, but the final question is aimed towards the experts.


I'm not sure why, but my first instinct was to use a reservation, rather than a quota. I thought (mistakenly) that perhaps the superuser might be able to circumvent a quota, but a quick test showed that my hunch was incorrect.

However, just for the sake of edification, consider using a reservation instead of a quota:

zfs create \
    -o reservation=500G \
    -o canmount=off \
    -o mountpoint=none storage/unusable

Beware that quotas and reservations use complementary numbers. In your example, your size figure of 2000GB is the amount of usable space you want to have. In the reservation example above, the 500GB is the amount of unusable space that will be withheld from the total space of the pool. Adjust to taste.

The differences are small, so I'm suggesting this just as an alternative solution, not as a "better way to do it." However, there is one slight advantage, which might not pay off until some day in the future.

With a quota, you never will be able to use that reserved space, not even as the superuser. But with a reservation, the superuser could possibly access that space:

zfs set canmount=noauto,mountpoint=/root/temporary storage/unusable
zfs mount /root/temporary

and have emergency access to that otherwise unusable portion of the pool. With a quota, I'm not aware of any way for even the superuser to override the storage limit.


To help illustrate what a reservation does to a pool, here is a tiny 4G virtual-disk pool with a 1G reservation:

# zfs list -o name,used,avail,reservation,refer,mountpoint -r mypool
mypool           1.00G  2.62G    none    88K  /mypool
mypool/unusable    88K  3.62G      1G    88K  none
mypool/usable      88K  2.62G    none    88K  /mypool/usable

# zpool list mypool
mypool  3.75G   744K  3.75G        -         -     0%     0%  1.00x  ONLINE  -
| improve this answer | |
  • Sorry, my mirror had some minor corruption and with the official release of native encryption I've been busy experimenting. At first I thought your idea was genius. A quota has issues. It can only grow and if reached, not even a delete is allowed. So why not do it the other way around? Then I got to thinking how this would work with the FS. If I reserve 20% in a child dataset, that 20% would likely not be considered free space in the parent pool, thus re-introducing the original problem of needing to keep 20% free space to facilitate efficient Copy-on-Write and prevent fragmentation. Right? – Mark May 25 '19 at 13:25
  • I am not sufficiently expert to give you a solid answer, but my instinct is: In ZFS, filesystems don't fill up, they share space in the pool with other filesystems. Only pools fill up. The reserved space is not used by the filesystem. It is simply marked as "off limits" to the other filesystem. It is truly "reserved." Think of tables at a restaurant, and 20% of them have a "reserved" sign on them. The restaurant is not full, it's just you that can't get a table. :) There is space left in the pool, you just can't use it. – Jim L. May 26 '19 at 1:19
  • On the other hand, the restaurant considers the reserved tables to be "untouchable". So they can't just shuffle the other diners around to make it more efficient for staff to serve them. The tables form a physically isolated spot that only the designated diners may touch, no matter how inconvenient or unproductive it may be. Will ZFS say t itself "I have a file that spans two tables, so let me take two reserved tables that are right next to one another, and move the reserved signs to two other tables that are NOT next to one another." To shuffle or not to shuffle, that's the question. – Mark Jun 2 '19 at 18:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.