Disk Quotas: Soft Limits, Hard Limits, and the Grace Period

Picture a shared filesystem — /home on a teaching server, /srv/share for a team, a volume several services write logs into. Nothing stops one account from filling it. A runaway script, a user who copies a video library into their home directory, a service that logs every request at debug level: when the filesystem hits 100%, every writer on it starts failing, not just the one that caused it. Mail stops delivering, editors can't save, databases refuse transactions. One account's mistake becomes everyone's outage.

A disk quota caps consumption per user or per group, per filesystem. It does not make the disk bigger and it does not clean anything up. What it does is shrink the blast radius: the account that goes over its limit is the account whose writes start failing, and everyone else keeps working. That is the whole job, and it is why quotas show up on every Linux certification that touches storage.

A quota caps two things independently. Blocks are space: how many kilobytes the user's files occupy on that filesystem. Inodes are file count: every file, directory and symlink uses one inode no matter how small it is. A user can be well inside their space limit and still be stopped by their inode limit — a build that writes two million tiny files, a mail spool with one file per message.

This is the same two-axis idea as df -h versus df -i: a filesystem can run out of space or out of inodes, and either one stops new files. Quotas apply that split per user. setquota and repquota always show the two columns side by side, so train your eye to read both before you conclude someone is fine.

Each axis has two limits. The hard limit is a wall: a write that would cross it fails immediately with Disk quota exceeded. The soft limit is lower, and it can be crossed — for a grace period set per filesystem. While the user is over the soft limit and the timer is running, their writes still succeed; they are being warned, not stopped.

When the grace period expires, the soft limit is enforced as a hard limit (that is exactly how edquota(8) puts it). The user now cannot write anything more until they get back under the soft limit, even though they are still below the hard limit. The design gives people room for a burst — a big download they'll clean up tomorrow — without letting a temporary burst become permanent. Set the soft limit where you want people to live, the hard limit where a burst must stop, and the grace period to how long a burst is allowed to last.

On ext4 (and ext3), enabling quotas is three separate steps, and stopping after the first one is the classic mistake. One: add the mount option — usrquota for per-user, grpquota for per-group — to the filesystem's /etc/fstab line and remount. That only declares intent. Two: run quotacheck to scan the filesystem and build the accounting files aquota.user / aquota.group at the filesystem's root. Three: run quotaon to start enforcing. Until step three, no limit is enforced no matter what the fstab line says.

setquota sets limits non-interactively, which makes it the tool for scripts and for exams. The argument order is fixed and worth memorising: name, block-soft, block-hard, inode-soft, inode-hard, filesystem. A 0 means no limit on that value. edquota does the same job by opening the limits in your editor — handy by hand, awkward to script.

Carry the ext4 recipe onto an XFS filesystem and it breaks in two places. First, accounting must be on at mount time. quotaon(8) states it plainly: XFS requires quota accounting to be turned on when the filesystem is mounted; enforcement can be toggled later, accounting cannot be started after the fact. So the mount option (uquota/usrquota, gquota/grpquota, pquota/prjquota) has to be present when XFS mounts — and for an XFS root filesystem that means the kernel command line, because root is mounted before fstab is read.

Second, there are no aquota files. XFS keeps quota information internally, not in user-visible files, so quotacheck has no role at all — running it is a sign you're following the wrong recipe. Limits and reports go through xfs_quota, whose -x (expert) mode carries the commands that change things. XFS also offers project quotas, which cap a directory tree regardless of who owns the files inside it — useful when the thing that fills a disk is an application directory, not a person.

Before you set a single limit, the first minute of any quota task is reading what's there: which filesystem, which type, which mount options, how close each axis already is. These reads run on any box, including one with no quotas at all — on the lab image they mostly report nothing is configured yet, and recognising that state is the skill. Run each one and say out loud what it tells you.