Implementing Disk Quotas

While it is always good to be aware of disk usage, there are many instances where it is even better to have a bit of control over it. That is what disk quotas can do.

Many times the first thing most people think of when they think about disk quotas is using it to force users to keep their directories clean. While there are sites where this may be the case, it also helps to look at the problem of disk space usage from another perspective. What about applications that, for one reason or another, consume too much disk space? It is not unheard of for applications to fail in ways that cause them to consume all available disk space. In these cases, disk quotas can help limit the damage caused by such errant applications, by forcing it to stop before no free space is left on the disk.

Some Background on Disk Quotas

Disk quotas are implemented on a per-file system basis. In other words, it is possible to configure quotas for /home (assuming /home is on its own file system), while leaving /tmp without any quotas at all.

Quotas can be set on two levels:

This kind of flexibility makes it possible to give each user a small quota to handle "personal" file (such as email, reports, etc.), while allowing the projects they work on to have more sizable quotas (assuming the projects are given their own groups).

In addition, quotas can be set not just to control the number of disk blocks consumed, but also to control the number of inodes. Because inodes are used to contain file-related information, this allows control over the number of files that can be created.

But before we can implement quotas, we should have a better understanding of how they work. The first step in this process is to understand the manner in which disk quotas are applied. There are three major concepts that you should understand prior to implementing disk quotas:

Hard Limit

The hard limit defines the absolute maximum amount of disk space that a user or group can use. Once this limit is reached, no further disk space can be used.

Soft Limit

The soft limit defines the maximum amount of disk space that can be used. However, unlike the hard limit, the soft limit can be exceeded for a certain amount of time. That time is known as the grace period.

Grace Period

The grace period is the time during which the soft limit may be exceeded. The grace period can be expressed in seconds, minutes, hours, days, weeks, or months, giving the system administrator a great deal of freedom in determining how much time to give users to get their disk usage below their soft limit.

With these terms in mind, we can now begin to configure a system to use disk quotas.

Enabling Disk Quotas

In order to use disk quotas, you must first enable them. This process involves several steps:

  1. Modifying /etc/fstab

  2. Remounting the file system(s)

  3. Running quotacheck

  4. Assigning quotas

Let us look at these steps in more detail.

Modifying /etc/fstab

Using the text editor of your choice, simply add the usrquota and/or grpquota options to the file systems that require quotas:

/dev/md0          /                  ext3    defaults        1 1
LABEL=/boot       /boot              ext3    defaults        1 2
none              /dev/pts           devpts  gid=5,mode=620  0 0
LABEL=/home       /home              ext3    defaults,usrquota,grpquota 1 2
none              /proc              proc    defaults        0 0
none              /dev/shm           tmpfs   defaults        0 0
/dev/md1          swap               swap    defaults        0 0

In this example, we can see that the /home file system has both user and group quotas enabled.

At this point you must remount each file system whose fstab entry has been modified. You may be able to simply umount and then mount the file system(s) by hand, but if the file system is currently in use by any processes, the easiest thing to do is to reboot the system.

Running quotacheck

When each quota-enabled file system is remounted, the system is now capable of working with disk quotas. However, the file system itself is not yet ready to support quotas. To do this, you must first run quotacheck.

The quotacheck command examines quota-enabled file systems, building a table of the current disk usage for each one. This table is then used to update the operating system's copy of disk usage. In addition, the file system's disk quota files are updated (or created, if they do not already exist).

In our example, the quota files (named aquota.group and aquota.user, and residing in /home/) do not yet exist, so running quotacheck will create them. Use this command:

quotacheck -avug

The options used in this example direct quotacheck to:

  • Check all quota-enabled, locally-mounted file systems (-a)

  • Display status information as the quota check proceeds (-v)

  • Check user disk quota information (-u)

  • Check group disk quota information (-g)

Once quotacheck has finished running, you should see the quota files corresponding to the enabled quotas (user and/or group) in the root directory of each quota-enabled file system (which would be /home/ in our example):

total 44
drwxr-xr-x    6 root     root         4096 Sep 14 20:38 .
drwxr-xr-x   21 root     root         4096 Sep 14 20:10 ..
-rw-------    1 root     root         7168 Sep 14 20:38 aquota.user
-rw-------    1 root     root         7168 Sep 14 20:38 aquota.group
drwx------    4 deb      deb          4096 Aug 17 12:55 deb
drwx------    9 ed       ed           4096 Sep 14 20:35 ed
drwxr-xr-x    2 root     root        16384 Jan 20  2002 lost+found
drwx------    3 matt     matt         4096 Jan 20  2002 matt

Now we are ready to begin assigning quotas.

Assigning Quotas

The mechanics of assigning disk quotas are relatively simple. The edquota program is used to edit a user or group quota:

 Disk quotas for user ed (uid 500):
  Filesystem      blocks       soft       hard     inodes     soft     hard
  /dev/md3       6618000          0          0      17397        0        0

edquota uses a text editor (which can be selected by setting the EDITOR environment variable to the full pathname of your preferred editor) to display and change the various settings. Note that any setting left at zero means no limit:

Disk quotas for user ed (uid 500):
  Filesystem      blocks       soft       hard     inodes     soft     hard
  /dev/md3       6617996    6900000    7000000      17397        0        0

In this example, user ed (who is currently using over 6GB of disk space) has a soft limit of 6.9GB and a hard limit of 7GB. No soft or hard limit on inodes has been set for this user.

TipTip
 

The edquota program can also be used to set the per-file system grace period by using the -t option.

Although the mechanics of this process are simple, the hardest part of the process always revolves around the limits themselves. What should they be?

A simplistic approach would be to simply divide the disk space by the number of users and/or groups using it. For example, if the system has a 100GB disk drive and 20 users, each user will be given a hard limit of no more than 5GB[1]. That way, each user would be guaranteed 5GB (although the disk would be 100% full at that point).

A variation on this approach would be to institute a soft limit of 5GB, with a hard limit somewhat above that — say 7.5GB. This would have the benefit of allowing users to permanently consume no more than their percentage of the disk, but still permitting some flexibility when a user reaches (and exceeds) their limit.

When using soft limits in this manner, you are actually over-committing the available disk space. The hard limit is 7.5GB. If all 20 users exceeded their soft limit at the same time, and attempted to reach their hard limits, that 100GB disk would actually have to be 150GB in order to allow everyone to reach their hard limit at the same time.

However, in practice not everyone will exceed their soft limit at the same time, making some amount of overcommitment a reasonable approach. Of course, the selection of hard and soft limits is up to the system administrator, as each site and user community is different.

Managing Disk Quotas

There is little actual management required to support disk quotas under Red Hat Linux. Essentially, all that is required is:

Let us look at these steps in more detail below.

Reporting on Disk Quotas

Creating a disk usage report entails running the repquota utility program. Using the command repquota /home produces this output:

*** Report for user quotas on device /dev/md3
Block grace time: 7days; Inode grace time: 7days
                        Block limits                File limits
User            used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
root      --   32836       0       0              4     0     0       
ed        -- 6617996 6900000 7000000          17397     0     0       
deb       --  788068       0       0          11509     0     0       
matt      --      44       0       0             11     0     0       

While the report is easy to read, a few points should be explained. The -- displayed after each user is a quick way to see whether the block or inode limits have been exceeded. If either soft limit is exceeded, a + will appear in place of the -; the first character representing the block limit and the second representing the inode limit.

The grace columns are normally blank; if a particular soft limit has been exceeded, the column will contain a time specification equal to the amount of time remaining on the grace period. Should the grace period expire, none will appear in its place.

Once a report has been generated, the real work begins. This is an area where a system administrator must make use of all the people skills they possess. Quite often discussions over disk space become emotional, as people view quota enforcement as either making their job more difficult (or impossible), that the quotas applied to them are unreasonably small, or that they just do not have the time to clean up their files to get below their quota again.

The best system administrators will take many factors into account in such a situation. Is the quota equitable, and reasonable for the type of work being done by this person? Does the person seem to be using their disk space appropriately? Can you help the person reduce their disk usage in some way (by creating a backup CD-ROM of all emails over one year old, for example)?

Approaching the situation in a sensitive but firm manner is often better than using your authority as system administrator to force a certain outcome.

Keeping Quotas Accurate With quotacheck

Whenever a file system is not unmounted cleanly (due to a system crash, for example), it is necessary to run quotacheck. However, many system administrators recommend running quotacheck on a regular basis, even if the system has not crashed.

The command format itself is simple; the options used have been described in the Section called Running quotacheck:

quotacheck -avug

The easiest way to do this is to use cron. From the root account, you can either use the crontab command to schedule a periodic quotacheck or place a script file that will run quotacheck in any one of the following directories (using whichever interval best matches your needs):

  • /etc/cron.hourly

  • /etc/cron.daily

  • /etc/cron.weekly

  • /etc/cron.monthly

Most system administrators choose a weekly interval, though there may be valid reasons to pick a longer or shorter interval, depending on your specific conditions. In any case, it should be noted that the most accurate quota statistics will be obtained by quotacheck when the file system(s) it analyzes are not in active use. You should keep this in mind when you schedule your quotacheck script.

Notes

[1]

Although it should be noted that Linux file systems are formatted with a certain percentage (by default, 5%) of disk space reserved for the super-user, making this example less than 100% accurate.