Red Hat Linux 8.0: The Official Red Hat Linux System Administration Primer | ||
---|---|---|
Prev | Chapter 5. Managing Storage | Next |
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.
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:
For individual users
For individual groups
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:
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.
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.
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.
In order to use disk quotas, you must first enable them. This process involves several steps:
Modifying /etc/fstab
Remounting the file system(s)
Running quotacheck
Assigning quotas
Let us look at these steps in more detail.
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.
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.
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.
Tip | |
---|---|
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.
There is little actual management required to support disk quotas under Red Hat Linux. Essentially, all that is required is:
Generating disk usage reports at regular intervals (and following up with users that seem to be having trouble effectively managing their allocated disk space)
Making sure that the disk quotas remain accurate
Let us look at these steps in more detail below.
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.
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.
[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. |