Carving a Storage Pool into Per-Project Quotas
The pool arrives as one number. The filesystem reports 100 TiB, or 240 TiB, or whatever survived the array layout, and now it has to become dozens of individual limits. Almost every tool that sets those limits — zfs set refquota, xfs_quota, an NFS appliance UI, a storage class request — is comfortable with gibibytes and awkward with fractional tebibytes, so the first thing a storage admin does with a pool figure is push it down a level.
Quota Commands Want GiB
2048G is unambiguous and easy to audit. The same limit written as 2 TiB reads fine in a wiki page but has to be translated before it becomes a command.Allocated Never Equals Pool
Two Ledgers to Keep
Both units are binary, so nothing is being reconciled between standards: 1 024 is the whole story and every result stays a clean power of two. That is exactly why quota planning is done in this pair — halve and double allocations all day and you never produce a fraction.
Turning a Pool Size into Quota Numbers
Start from what the pool actually reports
Take the tebibyte figure from zpool list, df -h or the array console — not the number on the purchase order. Fractions such as 43.6 are fine, and stray spaces are ignored.
Subtract your reserve before you divide
Read the gibibyte total, then take off your headroom policy — commonly 10 to 20 % for snapshot growth and free-space performance. What remains is the only number that should be divided among projects.
Copy each allocation into the command
The copy button returns the bare number with no unit and no thousands spacing, so it drops cleanly into refquota=…G, a Terraform variable or an allocation sheet. Ctrl+C in a field does the same.
Reverse it when you audit the granted total
Sum every quota you have issued in GiB, type that sum into the right-hand field and read the tebibyte equivalent — both fields are editable, and the swap button flips the page to GiB-first.
The searchable unit menus carry every storage unit, so a request phrased as "half a tebibyte" or an appliance reporting mebibytes is handled by retargeting one side rather than opening a second calculator.
Pool Capacity Split Across Project Quotas
This table walks a pool from its reported tebibyte size to the per-project gibibyte figure you would type into a quota command. It holds back a 10 % reserve, then divides the rest equally among twelve projects — change the divisor to your tenant count, but keep the reserve step.
| Pool size | Total capacity | 10 % reserve held back | Quota per project (12 projects) |
|---|---|---|---|
| 10 TiB | 10 240 GiB | 1 024 GiB | 768 GiB |
| 20 TiB | 20 480 GiB | 2 048 GiB | 1 536 GiB |
| 50 TiB | 51 200 GiB | 5 120 GiB | 3 840 GiB |
| 100 TiB | 102 400 GiB | 10 240 GiB | 7 680 GiB |
| 200 TiB | 204 800 GiB | 20 480 GiB | 15 360 GiB |
| 500 TiB | 512 000 GiB | 51 200 GiB | 38 400 GiB |
Every row lands on a whole gibibyte. Because the reserve is a percentage of a power-of-two total and the divisor is small, no tenant ends up with a limit 0.3 GiB off from its neighbour's — which removes an entire category of argument from the allocation meeting.
Live totals while you rebalance
The result updates on every keystroke, so trying twelve projects, then fifteen, then a larger share for the busy one is a matter of retyping rather than recalculating.
Numbers shaped for a quota sheet
Copy returns the value alone — no unit suffix, no thousands separators — which is what a CSV of tenant limits or a config template expects to receive.
Runs entirely in the page
Pool sizes and tenant names are internal infrastructure detail; the conversion happens locally in your browser once the page has loaded and nothing is transmitted.
Quota Questions Storage Admins Actually Hit
Why do quota tools expect the limit in gibibytes rather than tebibytes?
Granularity and auditability. Most tenants need somewhere between a few hundred gibibytes and a few tebibytes, and gibibytes give whole numbers across that whole range — 512, 2048, 6144 — where tebibytes force fractions like 0.5 or 1.75 that are easy to fat-finger. It also makes the ledger trivial to check: add a column of GiB values and compare it with the pool total in GiB. Tools such as zfs set quota accept a G suffix precisely because that is the resolution operators think at.
How much of a pool has to stay unallocated?
More than most people expect. A copy-on-write filesystem keeps an internal slop reserve so it can still free blocks when the pool is nearly full, and performance degrades well before that point because the allocator struggles to find contiguous space. Snapshots make it worse: retained snapshots hold blocks that deleted files used to occupy, so consumption rises even while tenants tidy up. A common rule is to treat 80 to 85 % of the pool as allocatable — on a 100 TiB pool that is 10 240 to 15 360 GiB you deliberately never grant.
What is the difference between ZFS refquota and quota on a project dataset?
quota caps everything the dataset accounts for — live data, snapshots and all descendants. refquota caps only what the dataset head currently references. The difference shows up the first time a tenant deletes a large directory: under quota, if a snapshot still holds those blocks the tenant sees no space returned; under refquota the live figure drops immediately and the snapshot costs pool space rather than tenant quota. That is why multi-tenant setups usually pair refquota with a matching reservation and manage snapshot growth centrally.
How far can granted quotas exceed the physical pool?
Thin provisioning means the sum of your quotas can legitimately exceed the pool, because tenants rarely fill their limits. Whether 1.5:1 or 3:1 is safe depends on observed fill rates, not a rule of thumb — archival datasets sitting at 90 % full tolerate almost no oversubscription, development scratch averaging 20 % full tolerates a great deal. Two guardrails make it survivable: track granted GiB and consumed GiB as separate numbers on the same dashboard, and reserve guaranteed space for the few tenants that cannot be allowed to hit a wall.
When is a soft quota with a grace period better than a hard limit?
A hard limit stops writes the instant it is reached, which protects the pool but can fail a job mid-run and leave half-written output. A soft limit lets the tenant continue past its allocation for a defined grace period — days on a traditional Unix quota system — while warning them, and only enforces when the grace expires. The usual pattern is a soft limit at the granted figure and a hard limit above it, say soft 2 048 GiB and hard 2 560 GiB. The gap absorbs one bad week; the hard number stops a runaway tenant eating the pool reserve.
No comments yet. Be the first to comment!