This chapter describes administration procedures for maintaining XFS filesystems that you perform on a routine or as-needed basis. It is extremely important to maintain filesystems properly, in addition to backing up the data they contain. Failure to do so might result in loss of valuable system and user information.
The major sections in this chapter are:
To administer filesystems, you need to do the following:
Monitor the amount of free space and free inodes available.
If a filesystem is chronically short of free space, take steps to alleviate the problem, such as removing old files and imposing disk usage quotas.
Back up filesystems.
Many routine administration jobs can be performed by shell scripts. Here are a few ideas:
Use a shell script to investigate free blocks and free inodes, and report on filesystems whose free space dips below a given threshold.
Use a shell script to automatically “clean up” files that grow (such as log files).
Use a shell script to highlight cases of excessive disk use.
These scripts can be run automatically with the cron command and the output can be sent to you using electronic mail. Typically, these scripts use some combination of the find, du, mail, and shell commands.
The process accounting system performs many similar functions. If the process accounting system does not meet your needs, examine the scripts in /usr/lib/acct, such as ckpacct and remove, for ideas about how to build your own administration scripts.
As explained in “Filesystem Mounting and Unmounting” in Chapter 5, in order to be accessed by IRIX, filesystems must be mounted. The following subsections explain the use of the mount and umount commands and the file /etc/fstab to mount and unmount filesystems.
The mount command is used to mount filesystems manually. The basic forms of the mount command are:
mount device_file mount_point_directory mount host:directory mount_point_directory |
device_file is a block device file. host:directory is the hostname and pathname of a remote directory that has been exported on the remote host by using the exportfs command on the remote host (it requires NFS). mount_point_directory is the mount point directory. The mount point must already exist (you can create it with the mkdir command).
If you omit either the device_file or the mount_point_directory from the mount command line, mount checks the file /etc/fstab to find the missing argument. See “Mounting Filesystems Automatically With the /etc/fstab File” for more information about /etc/fstab.
For example, to mount a filesystem manually, use this command:
mount /dev/dsk/dks0d1s6 /usr
Another example, which uses a mnemonic device file name, is:
mount /dev/usr /usr
An example of a mount command for a filesystem that is listed in /etc/fstab is:
mount /d2
Other useful mount commands are:
| mount -a | Mount all filesystems listed in /etc/fstab. | |
| mount -h host | Mount all filesystems listed in /etc/fstab that are remote-mounted from the system named host. | |
| mount -o quota device_file mount_point_directory | Mount the filesystem device_file at mount_point_directory with disk quota tracking turned on. See “Using Disk Quotas on XFS Filesystems” for more information. |
You can use the -t type option of the mount command to specify what type of filesystem you are mounting. For a description of the filesystem types that the IRIX operating system supports, see the filesystems(4) reference page.
See the mount(1M) reference page for more information about the mount command.
The /etc/fstab file contains information about every filesystem and swap partition that is to be mounted automatically when the system is booted into multi-user mode. In addition, the /etc/fstab file is used by the mount command when only the device block file or the mount point is given to the mount command. Filesystems that are not mounted with the mount command, such as the /proc filesystem, are not listed in /etc/fstab.
The procedure in this section explains how to add an entry for a filesystem to /etc/fstab.
For each filesystem that is to be mounted every time the system is booted, a line similar to this appears in the file /etc/fstab:
/dev/dsk/dks0d2s7 /test xfs rw,raw=/dev/rdsk/dks0d2s7 0 0 |
The fields in this line are defined as follows:
| /dev/dsk/dks0d2s7 | The block device file of the partition where the filesystem is located. | |
| /test | The name of the directory where the filesystem will be mounted (the mount point). | |
| xfs | The type of filesystem. In this case, the filesystem is an XFS filesystem. | |
| rw, raw= | These are some of many options available when mounting a filesystem (see the fstab(4) reference page for a complete list). In this instance, the filesystem is to be mounted read-write, so that root and other users can write to it. The raw= option gives the filesystem's raw device filename. It should be the last option in the options list. | |
| 0 0 | These two numbers represent the frequency of dump cycles and the fsck pass priority. These two numbers must be added after the last option in the options list (raw =). The fstab(4) reference page contains additional information. |
If you have already mounted the filesystem as described in the section “Manually Mounting Filesystems”, you can use the mount command to determine the appropriate /etc/fstab entry. For example:
mount -p
This command displays all currently mounted filesystems, including the new filesystem in /etc/fstab format. Copy the line that describes the new filesystem to /etc/fstab.
The mount command reads /etc/fstab sequentially; therefore, filesystems that are mounted beneath other filesystems must follow their parent partitions in /etc/fstab in order for their mount points to exist.
The swap partition on the system disk (partition 1) is not listed in /etc/fstab. However, additional swap partitions added to the system are listed. For swap partitions, the mount point field is not used. See the guide IRIX Admin: System Configuration and Operationand the swap(1M) reference page for more information.
See the fstab(4) reference page for more information about /etc/fstab entries.
If you have the optional NFS software, you can automatically mount any remote filesystem whenever it is accessed (for example, by changing directories to the filesystem with cd). The remote filesystem must be exported with the exportfs command.
For complete information about setting up automounting, including all the available options, see the automount(1M) and exportfs(1M) reference pages. These commands are discussed more completely in the ONC3/NFS Administrator's GuideONC3/NFS Administrator's Guide.
Filesystems are automatically unmounted when the system is shut down. To manually unmount filesystems, use the umount command. The three basic forms of the command are shown in Table 7-1. Local filesystems can be unmounted with either of the first two forms shown in the table; they are equivalent. Similarly, the first and third forms are equivalent for remote filesystems.
Table 7-1. Forms of the umount Command
Command | Comments |
|---|---|
umount mount_point_directory | mount_point_directory is a directory pathname that is the mount point for the filesystem. This form can be used for local or remote filesystems. |
umount device_file | device_file is a block device file name. This form is only for local filesystems. |
umount host :directory | host:directory is a remote directory. This form is only for remote filesystems. |
umount -a | Attempt to unmount all the filesystems currently mounted (listed in /etc/mtab) except / and /usr. This command is not the complement of the mount -a command, which mounts all filesystems listed in /etc/fstab. |
For example, to unmount a local or remote filesystem mounted at /d2, give this command:
umount /d2
To unmount the filesystem on the partition /dev/dsk/dks0d1s7, give this command:
umount /dev/dsk/dks0d1s7
To unmount the remote-mounted (NFS) filesystem depot:/usr/spool/news, give this command:
umount depot:/usr/spool/news
To be unmounted, a filesystem must not be in use. If it is in use and you try to unmount it, you get a Resource busy message. Error messages and their solutions are explained in the umount(1M) reference page.
At some point, you are likely to find yourself short on disk space. In addition to using disk space intentionally for new files, you and other users may be creating and retaining files that you do not need.
People tend to forget about files they no longer use. Outdated files often stay on the system much longer than necessary.
Some files, particularly log files such as /var/adm/SYSLOG, grow as a result of normal system operations. Normally, cron rotates this file once per week so that it does not grow excessively large. (See /var/spool/cron/crontabs/root.) However, you should check this file periodically to make sure it is being rotated properly, or when the amount of free disk space has grown small.
Some directories, notably /tmp, /usr/tmp, and /var/tmp, accumulate files. These are often copies of files being manipulated by text editors and other programs. Sometimes these temporary files are not removed by the programs that created them.
The directories /usr/tmp, /var/tmp, and /var/spool/uucppublic are public directories; people often use them to store temporary copies of files they are transferring to and from other systems and sites. Unlike /tmp, they are not cleaned out when the system is rebooted. The site administrator should be even more conscientious about monitoring disk use in these directories.
Users move old files to the dumpster without realizing that such files are not fully deleted from the system.
vmcore and unix files in /var/adm/crash are accumulating without being removed.
Binary core dumps, core files, from crashed application programs are not being removed.
Tip: The section “Freeing Disk Space” in Chapter 6 of the Personal System Administration Guide provides additional ideas for identifying unnecessary files.
The following subsections describe various techniques for monitoring disk space usage, locating unneeded files, and limiting disk usage by individual users.
You can quickly check the amount of free space and free inodes with the df command. For example,
% df Filesystem Type blocks use avail %use Mounted on /dev/root xfs 1939714 1326891 612823 68% / |
The avail column shows the amount of free space in blocks.
To determine the number of free inodes, use this command:
% df -i Filesystem Type blocks use avail %use iuse ifree %iuse Mounted /dev/root xfs 1939714 1326891 612823 68% 14491 195031 7% / |
You see a listing similar to the first df listing, except that it also lists the number of inodes in use, the number of inodes that are free (available), and the percentage of inodes in use. For XFS filesystems, the number of free inodes is the maximum number that could be allocated if needed. XFS allocates inodes as needed. On XFS filesystems inode usage is very high only on very full filesystems. XFS filesystem performance does not degrade when XFS filesystems are very full.
Almost any system that is used daily has several key files and directories that grow through normal use. Some examples are shown in Table 7-2.
Table 7-2. Files and Directories That Tend to Grow
File | Use |
|---|---|
/etc/wtmp | History of system logins |
/tmp | Directory for temporary files (root filesystem) |
/var/adm/avail/availlog | Log file for the availability monitor (see the availmon(5) reference page) |
/var/adm/avail/notifylog | Log file for the availability monitor (see the availmon(5) reference page) |
/var/adm/sulog | History of su commands |
/var/cron/log | History of actions of cron |
/var/spool/lp/log | History of actions of lp |
/var/spool/uucp | Directory for uucp log files |
/var/tmp | Directory for temporary files |
The frequency with which you should check growing files depends on how active your system is and how critical the disk space problem is. A good technique for keeping them down to a reasonable size uses a combination of the tail and mv commands:
# tail -50 /var/adm/sulog > /var/tmp/sulog # mv /var/tmp/sulog /var/adm/sulog |
This sequence puts the last 50 lines of /var/adm/sulog into a temporary file, then moves the temporary file to /var/adm/sulog. This reduces the file to the 50 most recent entries. It is often useful to have these commands performed automatically every week using cron. For more information on using cron to automate your regular tasks, see the cron(1M) reference page.
The directory /tmp and all of its subdirectories are automatically cleaned out every time the system is rebooted. You can control whether or not this happens with the chkconfig option nocleantmp. By default, nocleantmp is off, and thus /tmp is cleaned.
The directory /var/tmp is not automatically cleaned out when the system is rebooted. This is a fairly standard practice on IRIX systems. If you wish, you can configure IRIX to clean out /var/tmp automatically whenever the system is rebooted. Changing this standard policy is a fairly extreme measure, and many people expect that files left in /var/tmp are not removed when the system is rebooted. Do not make this change without warning users well in advance.
To configure IRIX to clean out /var/tmp automatically at system reboot, follow these steps:
Notify everyone who uses the system that you are changing the standard policy regarding /var/tmp, and that all files left in /var/tmp will be removed when the system is rebooted. Send electronic mail and post a message in the /etc/motd file.
Give the users at least one week's notice, longer if possible.
Copy the file /etc/init.d/rmtmpfiles to a new file in the same directory, for example, /etc/init.d/rmtmpfiles2:
# cd /etc/init.d # cp rmtmpfiles rmptmpfiles2
Open rmtmpfiles2 for editing, for example:
# vi rmtmpfiles2
Find a block of commands in the file that looks something like this:
# make /var/tmp exist if [ ! -d /var/tmp ] then rm -f /var/tmp # remove the directory mkdir /var/tmp fiBefore the fi statement add the following lines:
else # clean out /var/tmp rm -f /var/tmp/*The complete block of commands should look something like this:
# make /var/tmp exist if [ ! -d /var/tmp ] then rm -f /var/tmp # remove the directory mkdir /var/tmp else # clean out /var/tmp rm -f /var/tmp/* fiSave the file and exit the editor.
Create a link to the new file in the directory /etc/rc2.d, following the naming conventions described in /etc/init.d/README. For example:
# cd ../rc2.d # ln -s ../init.d/rmtmpfiles S59rmtmpfiles2
Part of the job of cleaning up filesystems is locating and removing files that have not been used recently. The find command can locate files that have not been accessed recently.
The find command searches for files, starting at a directory named on the command line. It looks for files that match whatever criteria you wish, for example all regular files, all files that end in .trash, or any file older than a particular date. When it finds a file that matches the criteria, it performs whatever task you specify, such as removing the file, printing the name of the file, changing the file's permissions, and so forth.
For example:
# find /usr -local -type f -mtime +60 -print > /usr/tmp/deadfiles & |
In the above example:
| /usr | specifies the pathname where find is to start. | |
| -local | restricts the search to files on the local system. | |
| -type f | tells find to look only for regular files and to ignore special files, directories, and pipes. | |
| -mtime +60 | says you are interested only in files that have not been modified in 60 days. | |
means that when a file is found that matches the -type and -mtime expressions, you want the pathname to be printed. | ||
| > /usr/tmp/deadfiles & | directs the output to the temporary file /usr/tmp/deadfiles and runs in the background. Redirecting the results of the search in a file is a good idea if you expect a large amount of output. |
As another example, you can use the find command to find files over 7 days old in the temporary directories and remove them. Use the following commands:
# find /var/tmp -local -type f -atime 7 -exec rm {} \;
# find /tmp -local -type f -atime 7 -exec rm {} \;
|
This example shows how to use find to locate and remove all core files over a week old:
# find / -local -type f -name core -atime +7 -exec rm {} \;
|
See the cron(1M) reference page for information on using the cron command to automate the process of locating and possibly removing.
A number of commands are useful for tracking down accounts that use large amounts of space: du, find, quota commands, and diskusg. Their use is described in the following subsections.
du displays disk use, in blocks, for files and directories. For example:
# du /usr/share/catman/u_man 5 /usr/share/catman/u_man/cat1/audio 266 /usr/share/catman/u_man/cat1/Xm 1956 /usr/share/catman/u_man/cat1/X11 72 /usr/share/catman/u_man/cat1/Inventor 413 /usr/share/catman/u_man/cat1/dmedia 752 /usr/share/catman/u_man/cat1/explorer 12714 /usr/share/catman/u_man/cat1 1 /usr/share/catman/u_man/cat3/audio 63 /usr/share/catman/u_man/cat3 12 /usr/share/catman/u_man/cat6/video 1077 /usr/share/catman/u_man/cat6 92 /usr/share/catman/u_man/cat2 425 /usr/share/catman/u_man/cat4 170 /usr/share/catman/u_man/cat5 13 /usr/share/catman/u_man/cat1m 14557 /usr/share/catman/u_man |
This displays the block count for all directories in the directory /usr/share/catman/u_man. By default the du command displays disk use in 512-byte blocks. To display disk use in 1024-byte blocks, use the -k option. For example:
# du -k /usr/people/ralph |
The -s option produces a summary of the disk use in a particular directory. For example:
# du -s /usr/people/alice |
For a complete description of du and its options, see the du(1M) reference page.
Use find to locate specific files that exceed a given size limit. For example:
# find /usr -local -type f -size +10000 -print |
This example produces a display of the pathnames of all files in the usr filesystem that are larger than 10,000 512-byte blocks.
The disk quotas system, described in the section “Disk Quotas” in Chapter 5, can be used to monitor disk space usage without enforcing disk usage limits. Disk quota accounting can be enabled by user, by group, or by project. Disk quota accounting by user and disk quota accounting by group are mutually exclusive.
On XFS filesystems, use these commands to turn on disk usage accounting without enforcement, stop disk usage accounting, and report disk space usage:
To turn on disk usage accounting automatically on a filesystem for user quotas, include the option qnoenforce in the /etc/fstab entry, for example:
/dev/root / xfs rw,qnoenforce,raw=/dev/rroot 0 0
To turn on disk usage accounting automatically on a filesystem for group quotas, include the option gqnoenforce in the /etc/fstab entry, for example:
/dev/root / xfs rw,gqnoenforce,raw=/dev/rroot 0 0
To turn on disk usage accounting automatically on a filesystem for project quotas, include the option pqnoenforce in the /etc/fstab entry, for example:
/dev/root / xfs rw,pqnoenforce,raw=/dev/rroot 0 0
To turn on disk usage accounting manually for user quotas on a non-root filesystem, when mounting the filesystem, use this mount command:
# mount -o qnoenforce fsname rootdir
fsname is the device name of the filesystem. rootdir is the directory where the filesystem is mounted.
To turn on disk usage accounting manually on a non-root filesystem for group quotas when mounting the filesystem, use this mount command:
# mount -o gqnoenforce fsname rootdir
To turn on disk usage accounting manually on a non-root filesystem for project quotas when mounting the filesystem, use this mount command:
# mount -o pqnoenforce fsname rootdir
To turn on disk usage accounting manually on the root filesystem for user quotas, execute the following commands. The quotaon command turns on disk accounting with enforcement, and the quotaoff -o command turns off the enforcement.
# /usr/etc/quotaon -v / # /usr/etc/quotaoff -v -o enforce / # reboot
To turn on disk usage accounting manually on the root filesystem for group quotas, give these commands:
# /usr/etc/quotaon -v -o gquota / # /usr/etc/quotaoff -v -o gqenforce / # reboot
To turn on disk usage accounting manually on the root filesystem for project quotas, give these commands:
# /usr/etc/quotaon -v -o pquota / # /usr/etc/quotaoff -v -o pqenforce / # reboot
To stop disk usage accounting on a filesystem for user quotas, give this command:
# /usr/etc/quotaoff fsname
To stop disk usage accounting on a filesystem for group quotas, give this command:
# /usr/etc/quotaoff -o gquota fsname
To stop disk usage accounting on a filesystem for project quotas, give this command:
# /usr/etc/quotaoff -o pquota fsname
To get information about disk usage, use the commands described in “Checking Disk Space Usage With quot ” and “Checking Disk Space Usage on XFS Filesystems With quota ”.
The quot command reports the amount of disk usage per user on a filesystem. It is part of the disk quotas system, although you need not use quotas to use this command. On XFS filesystems, you must turn on user quotas even if you don't enforce the limits; for instructions see “Monitoring Disk Space Usage with Disk Quota Accounting”.
Y ou can use the output of the quot command to inform your users of their disk space usage. An example of the command that displays disk space usage (on the root filesystem in this example), is:
# /usr/etc/quot /
/dev/root (/):
371179 root
265712 ellis
12606 aevans
7927 demos
5526 bin
2744 lp
682 uucp
379 guest
207 adm
7 sys
|
The quota command reports the amount of disk usage per user, per group, or per project on a filesystem, as well as additional information about the disk quotas. On XFS filesystems, you must turn on quotas to use this feature, even if you are not going to enforce quota limits. For instructions on monitoring disk space usage without enforcing disk usage limits see “Monitoring Disk Space Usage with Disk Quota Accounting”.
For information on the output of the quota command, see “Displaying Disk Quota Information on XFS Filesystems”.
The diskusg command is part of the process accounting subsystem and serves the same purpose as quot. diskusg, however, is typically used as part of general system accounting. This command generates disk usage information on a per-user basis. For example,
# /usr/lib/acct/diskusg /dev/root 0 root 736795 2 bin 11035 3 uucp 1342 4 sys 9 5 adm 1011 9 lp 5418 126 ellis 528263 993 demos 15737 998 guest 740 5315 aevans 24836 |
diskusg prints one line for each user identified in the /etc/passwd file. Each line contains the user's UID number and login name, and the total number of 512-byte blocks of disk space currently being used by the account.
The output of diskusg is normally the input to acctdisk (see the acct(1M) reference page), which generates total disk accounting records that can be merged with other accounting records. For more information on the accounting subsystem, consult IRIX Admin: Backup, Security, and Accounting and the acct(4) reference page.
For systems that have separate root and usr filesystems, running out of disk space on the root filesystem can occur for several reasons:
New software options that place files in the root filesystem have been installed.
A new IRIX release that requires more disk space in the root filesystem has been installed.
Files created while filesystems were unmounted have been unintentionally placed in the root filesystem instead of their intended filesystem. For example, suppose that the usr filesystem is unmounted and the file /usr/tempfile is created. When the usr filesystem is mounted at /usr, the file /usr/tempfile is not accessible, but it is still using disk space.
Applications that create files in /tmp are creating many files or very large files that fill up the root filesystem.
You can pursue several possible courses of action when the root filesystem is too full:
Check for hidden files. Unmount filesystems other than the root filesystem (you may find this easiest to do from the miniroot) and list the contents of each of the mount point directories.
Check the /lost+found directory. You may find that large files have accumulated there.
Increase the size of the root filesystem by combining the root and usr filesystems or by making the root filesystem larger by taking disk space from the usr filesystem.
Identify applications that are creating files in /tmp and cause the most problems, and configure them to use /usr/tmp instead of /tmp for temporary files. Most applications recognize the TMPDIR environment variable, which specifies the directory to use instead of the default. For example, with csh:
% setenv TMPDIR /usr/tmp
With sh:
% TMPDIR=/usr/tmp ; export TMPDIR
Make /tmp a mounted filesystem. (See “Mount a Filesystem as a Subdirectory” in Chapter 5.) You can “carve” a /tmp filesystem out of other filesystems if necessary.
This section describes basic commands for administering disk quotas on XFS filesystems. Additional commands are described on the quota(1), edquota(1M), quot(1M), and repquota(1M) reference pages.
You can set disk quotas for individual users, you can set disk quotas for groups according to group ID, and you can set disk quotas for projects, according to project ID. For information on group and project IDs and how they are established, see IRIX Admin: Backup, Security, and Accounting.Use of disk quota limits for groups and use of disk quota limits for projects are mutually exclusive.
For XFS filesystems, you must first turn on disk quotas on a filesystem, then set quotas on that filesystem for users and projects or groups.
You can turn on quotas for users in these ways:
To turn on disk quotas automatically for users on a filesystem, include the option quota in the /etc/fstab entry, for example:
/dev/xlv/foo /foo xfs rw,quota,raw=/dev/rxlv/foo 0 0
To turn on disk quotas manually for users on a non-root filesystem, mount the filesystem with this command:
# mount -o quota fsname rootdir
fsname is the device name of the filesystem. rootdir is the directory where the filesystem is mounted.
To turn on disk quotas manually for users on the root filesystem, give these commands:
# /usr/etc/quotaon -v / # reboot
You can turn on quotas for groups in these ways:
To turn on disk quotas automatically for groups on a filesystem, include the option gquota in the /etc/fstab entry, for example:
/dev/xlv/foo /foo xfs rw,gquota,raw=/dev/rxlv/foo 0 0
To turn on disk quotas manually for groups on a non-root filesystem, mount the filesystem with this command:
# mount -o gquota fsname rootdir
fsname is the device name of the filesystem. rootdir is the directory where the filesystem is mounted.
To turn on disk quotas manually for groups on the root filesystem, give these commands:
# /usr/etc/quotaon -o gquota -v / # reboot
Use of disk quota limits for groups and use of disk quota limits for projects are mutually exclusive.
You can turn on quotas for projects in these ways:
To turn on disk quotas automatically for projects on a filesystem, include the option pquota in the /etc/fstab entry, for example:
/dev/xlv/foo /foo xfs rw,pquota,raw=/dev/rxlv/foo 0 0
To turn on disk quotas manually for projects on a non-root filesystem, mount the filesystem with this command:
# mount -o pquota fsname rootdir
fsname is the device name of the filesystem. rootdir is the directory where the filesystem is mounted.
To turn on disk quotas manually for projects on the root filesystem, give these commands:
# /usr/etc/quotaon -o pquota -v / # reboot
Use of disk quota limits for groups and use of disk quota limits for projects are mutually exclusive.
After turning on disk quotas on a filesystem, you can set limits for users on that filesystem using the commands below. You can preview the results of each of these commands by adding a -n option, which is the dry-run option.
To specify limits for users interactively, give this command:
# /usr/etc/edquota name ...
name is a user name or numeric user ID. The screen clears, and you are placed in the editor specified by the EDITOR environment variable (vi if $EDITOR is not set) to edit the disk quotas for the filesystem mounted at rootdir for the first user listed on the command line. You see:
fs rootdir kbytes (soft = 0, hard = 0) inodes (soft = 0, hard = 0)
The first pair of soft and hard numbers are the soft and hard limits for disk usage in kilobytes in the filesystem at rootdir. The second pair of soft and hard numbers are the soft and hard limits for the number of files that user can own in the filesystem.
Edit the zeros to set the limits to sizes you choose. A limit of zero is not enforced. After you set the limits, save the file and quit the editor. If you specified more than one user on the command line, another instance of the editor appears with the line above. Edit this line to enter the limits for the second user. Continue until lines have been edited for all users.
To specify that users are to have the same limits as another user (proto_name), enter this command:
# /usr/etc/edquota -p proto_name name ...
To specify limits for a user non-interactively, enter this command:
# /usr/etc/edquota -f rootdir -l \ uid=userid,bsoft=kvalue,bhard=kvalue,isoft=value,ihard=value
userid is a user name or numeric user ID. Each kvalue is a soft or hard limit for disk usage in kilobytes.Each value is a soft or hard limit for the number of files the user can own.
To use the file (quotafile) created by command repquota -e (see the section “Administering Disk Quotas on XFS Filesystems”) as input to the edquota command, enter this command:
# /usr/etc/edquota -i quotafile
After turning on disk quotas on a filesystem, you can set limits for groups on that filesystem. You set limits for groups just as you do for users, by using the edquota command as described in “Setting Disk Quota Limits for Users on XFS Filesystems”.
To use the edquota command to set limits for a project, you include the -g option on the command line. When you use the -g option with edquota, any name specified on the command line is considered a group name. For example, to specify limits for groups interactively, give this command:
# /usr/etc/edquota -g name ... |
name is a group name or numeric group ID. For information on additional options of the edquota command, see the edquota(1M) man page.
Use of disk quota limits for groups and use of disk quota limits for projects are mutually exclusive.
After turning on disk quotas on a filesystem, you can set limits for projects on that filesystem. You set limits for projects just as you do for users, by using the edquota command as described in “Setting Disk Quota Limits for Users on XFS Filesystems”.
To use the edquota command to set limits for a project, you include the -j option on the command line. When you use the -j option with edquota, any name specified on the command line is considered a project name. For example, to specify limits for projects interactively, give this command:
# /usr/etc/edquota -j name ... |
name is a project name or numeric project ID. For information on additional options of the edquota command, see the edquota(1M) man page.
Use of disk quota limits for groups and use of disk quota limits for projects are mutually exclusive.
Some commands that display information about disk quotas are as follows:
To display a report that shows whether disk quotas are on or off for each filesystem, give this command as superuser:
# /usr/etc/repquota -sa /dev/root (/): -------------- Status user quota accounting : on user quota limit enforcement: on proj quota accounting : off proj quota limit enforcement: off group quota accounting : off group quota limit enforcement: off Quota Storage user quota inum 103156, blocks 8, extents 7 proj quota inum 103157, blocks 5, extents 4 Default Limits blocks time limit: 1.0 week files time limit: 1.0 week Cache dquots currently cached in memory: 14 --------------------The sections of the output are as follows:
Status Lists the status of disk space accounting (on or off) and enforcement of disk quotas (on or off) for this filesystem.
Quota Storage Blocks and extents are the number of filesystem blocks and extents used to store disk quota information. The inum value is the inode number at which quota information is stored and is for internal use only.
Default Limits The blocks and files time limits are the default lengths of time for this filesystem that users have to reduce their disk space usage or number of files below their soft limits. These time limits can be set on a per-user basis by the command edquota -t.
Cache This section is for internal use only
To get information about your disk quotas, enter this command:
# quota -v Disk quotas for margo (uid 1606): Filesystem usage quota limit timeleft files quota limit timeleft / 138360 0 0 14971 0 0 /e 4156360 41200 0 1.6 days 222264 0 0
The columns in this output are:
Filesystem Lists each of the filesystems that have quotas turned on.
usage Lists the user's disk usage on each filesystem.
quota The user's soft limit for disk usage or files on each filesystem.
limit The user's hard limit for disk usage or files on each filesystem.
timeleft For filesystems where the user's soft limit for disk usage or files is exceeded, gives the number of days until the user is prohibited from using additional disk space or creating more files.
files The number of files owned by the user on each filesystem.
To get information about your group disk quotas, enter this command:
# quota -g -v Disk quotas for staff (gid 50): Filesystem usage quota limit timeleft files quota limit timeleft /part1 4 0 0 2 0 0
To get information about your project disk quotas, enter this command:
# quota -j -v Disk quotas for xfsproj (projid 260): Filesystem usage quota limit timeleft files quota limit timeleft /sprite01 230 0 0 17 0 0
To get information about the disk usage and quotas of all users, enter this command:
# /usr/etc/quot -a
If the filesystem being dumped contains quotas, xfsdump will use repquota(1M) to store the quotas in the following three files in the root of the filesystem to be dumped:
| xfsdump_quotas | user quotas | |
| xfsdump_quotas_proj | project quotas | |
| xfsdump_quotas_group | group quotas |
These files will then be included in the dump. These files will appear only for those quotas which are enabled on the filesystem being dumped. Upon restoration, edquota(1M) can be used to reactivate the quotas for the filesystem. Note, however, that the xfsdump_quotas file will probably require modification to change the filesystem or UIDs if the filesystem has been restored to a different partition or system.
To create a file that lists the current quota limits of all the filesystems for users, enter this command as superuser:
# /usr/etc/repquota -a -e quotafile |
To create a file that lists the current quota limits of all the filesystems for groups, enter this command as superuser:
# /usr/etc/repquota -g -a -e quotafile |
To create a file that lists the current quota limits of all the filesystems for projects, enter this command as superuser:
# /usr/etc/repquota -j -a -e quotafile |
If you are familiar with using disk quotas on EFS filesystems, note that some quota commands that are used on EFS filesystems are not used on XFS filesystems. These commands are:
quotacheck. There is no need to run quotacheck manually.
chkconfig quota on and chkconfig quota off. Disk quotas are turned on during mounting, so mount options control whether disk quotas are on or off, not chkconfig.
chkconfig quotacheck on and chkconfig quotacheck off. quotacheck is not used on XFS filesystems so these chkconfig commands have no effect.
/etc/init.d/quotas start. This command has no effect on disk quota tracking on XFS systems.
touch quotas. There is no need to create files called quotas in the root directory of each filesystem. Quota information is hidden in the XFS filesystem structure.
repquota by non-superusers. Only the superuser can use the repquota command on XFS filesystems.
The xfs_copy command can be used to copy an XFS filesystem with an internal log (XFS filesystems with external logs or real-time subvolumes cannot be copied with xfs_copy). One or more copies can be created on disk partitions, logical volumes, or files. Each copy has a unique filesystem identifier, which enables them to be run as separate filesystems on the same system. (Programs that do block-by-block copying, such as dd, do not create unique filesystem identifiers.) Multiple copies are created in parallel. For more information, see the xfs_copy(1M) reference page.
An example of the xfs_copy command is:
# xfs_copy /dev/dsk/dks0d3s7 /dev/dsk/dks5d2s7 ... 10% ... 20% ... 30% ... 40% ... 50% ... 60% ... 70% ... 80% ... 90% ... 100% Done. All copies completed. |
XFS filesystem consistency checking can be done using the xfs_check command and the dry-run mode of the xfs_repair command. The xfs_repair command is sometimes able to repair filesystem inconsistencies.
The filesystem consistency checking commands for XFS filesystems are xfs_check and xfs_repair -n. (fsck is used only for EFS filesystems.) Unlike fsck, neither xfs_check nor xfs_repair are invoked automatically on system startup. They should be used only if you suspect a filesystem consistency problem.
Before running xfs_check or xfs_repair -n, the filesystem to be checked must be unmounted cleanly using normal system administration procedures (the umount command or system shutdown), not as a result of a crash or system reset. If the filesystem has not been unmounted cleanly, mount it and unmount it cleanly before running xfs_check or xfs_repair -n.
xfs_repair -n checks XFS filesystem consistency. xfs_repair -n performs a more complete check than xfs_check, but cannot be used to check filesystems with extended attributes or filesystems on XLV real-time subvolumes. The command line for xfs_repair -n is:
# xfs_repair -n device |
device is the device file for a disk partition or logical volume that contains an XFS filesystem, for example /dev/xlv/xlv0.
The following example shows output with no consistency problems found:
Phase 1 - find and verify superblock...
Phase 2 - scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan (but don't clear) agi unlinked lists...
- process known inodes and perform inode discovery...
- process newly discovered inodes...
- agno = 0
- agno = 1
...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
...
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
- traversing filesystem starting at / ...
- traversal finished ...
- traversing all unattached subtrees ...
- traversals finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.
|
xfs_check also checks XFS filesystem consistency. It can be used on filesystems with Extended Attributes (see the attr(1) reference page). (xfs_repair performs only limited checking of Extended Attributes.) The command line for xfs_check is:
# xfs_check device |
If no consistency problems were found, xfs_check returns without displaying any messages.
xfs_repair (without the -n option) checks XFS filesystem consistency and, if problems are detected, corrects them if possible. The filesystem to be checked and repaired must have been unmounted cleanly using normal system administration procedures (the umount command or system shutdown), not as a result of a crash or system reset. If the filesystem has not been unmounted cleanly, mount it and unmount it cleanly before running xfs_repair.
The command line for xfs_repair when you want it to repair any inconsistencies it finds is:
# xfs_repair device |
device is the device file for a disk partition or logical volume that contains an XFS filesystem, for example /dev/xlv/xlv0. It must not be mounted.
An example of the output you see from running xfs_repair on a clean filesystem is:
Phase 1 - find and verify superblock...
Phase 2 - zero log...
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
...
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- clear lost+found (if it exists) ...
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
...
Phase 5 - rebuild AG headers and trees...
- reset superblock counters...
Phase 6 - check inode connectivity...
- ensuring existence of lost+found directory
- traversing filesystem starting at / ...
- traversal finished ...
- traversing all unattached subtrees ...
- traversals finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done
|
For information about using xfs_repair on an inconsistent filesystem, see “Repairing XFS Filesystem Problems”.
The IRIX operating system provides the fpck command to check and repair hfs (mac) and dos (fat) filesystems. When the fpck utility locates major filesystem structure destruction, such as critical sector damage or an unrecoverable error, it gives an error message. For less severe filesystem inconsistencies, it gives a warning message
 | Note: For repair of foreign filesystems, it can be more constructive to use the filesystem repair tools of the foreign operating system. |
For information on using the fpck utility, see the fpck(1M) reference page. For further information on foreign filesystem types, see the filesystems(4) reference page. For information on creating foreign filesystems, see the mkfp(1M) reference page.
The xfs_repair command checks XFS filesystem consistency and sometimes repairs problems that are found. This section describes the messages that you may see from xfs_repair and what to do if xfs_repair is not able to repair a filesystem.
Some common error messages from xfs_repair and the repairs that it performs are the following:
| disconnected inode 242002, moving to lost+found | xfs_repair found an inode that is in use, but is not connected to the filesystem. The inode is moved to the filesystem's lost+found directory. Its name is its inode number, in this example 242002. If the disconnected inode is a directory, the directory's subtree is preserved—all its child inodes are automatically moved with it, so the entire directory subtree moves to lost+found. | |
| imap claims in-use inode 2444941 is free, correcting imap | The inode allocation map in the filesystem behaves as if inode 2444941 is free, but the inode itself looks like it is still in use. xfs_repair corrects the inode map to say that the inode is in use. | |
| entry references free inode 2444940 in shortform directory 2444922 junking entry “fb” in directory inode 2444922 | A directory entry points to an inode that xfs_repair has determined is actually free. xfs_repair junks the directory entry. The term shortform means a small directory. In larger directories, the entry deletion is usually a two-pass process. In this case, the second part of the message reads something like marking bad entry, marking entry to be deleted, or will clear entry. | |
| resetting inode 241996 nlinks from 5 to 3 | xfs_repair detected a mismatch between the number of directory entries pointing to the inode (links) and the number of links recorded in the inode. It corrected the number (from 5 to 3 in this case). | |
| cleared inode 2444926 | There was something wrong with the inode that was not correctable, so xfs_repair turned it into a zero-length free inode. This usually happens because the inode claims blocks that are used by something else or the inode itself is badly corrupted. Typically, the cleared inode message is preceded by one or more messages indicating why the inode needs to be cleared. |
If xfs_repair has put files and directories in a filesystem's lost+found directory and you do not remove them, the next time you run xfs_repair it temporarily disconnects the inodes for those files and directories. They are reconnected before xfs_repair terminates. As a result of the disconnected inodes in lost+found, you see output like this:
Phase 1 - find and verify superblock...
Phase 2 - zero log...
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
...
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- clear lost+found (if it exists) ...
- clearing existing “lost+found” inode
- deleting existing “lost+found” entry
- check for inodes claiming duplicate blocks...
- agno = 0
imap claims in-use inode 242000 is free, correcting imap
- agno = 1
- agno = 2
...
Phase 5 - rebuild AG headers and trees...
- reset superblock counters...
Phase 6 - check inode connectivity...
- ensuring existence of lost+found directory
- traversing filesystem starting at / ...
- traversal finished ...
- traversing all unattached subtrees ...
- traversals finished ...
- moving disconnected inodes to lost+found ...
disconnected inode 242000, moving to lost+found
Phase 7 - verify and correct link counts...
done
|
In this example, inode 242000 was an inode that was moved to lost+found during a previous xfs_repair run. This run of xfs_repair found that the filesystem is consistent. If the lost+found directory had been empty, in phase 4 only the messages about clearing and deleting the lost+found directory would have appeared. The left-justified imap claims and disconnected inode messages appear (one pair of messages per inode) if there are inodes in the lost+found directory.
If xfs_repair fails to repair the filesystem successfully, try giving the same xfs_repair command twice more; xfs_repair may be able to make more repairs on successive runs. If xfs_repair fails to fix the consistency problems in three tries, your next step depends upon where it failed:
If xfs_repair failed in phase 1, you must restore lost files from backups.
If xfs_repair failed in phase 2 or later, you may be able to restore files from the disk by backing up and restoring the files on the filesystem.
If xfs_repair failed in phase 2 or later, follow these steps:
Mount the filesystem using mount –r (read-only).
Make a filesystem backup with xfsdump.
Use mkfs to a make new filesystem on the same disk partition or XLV logical volume.
Restore the files from the backup with xfsrestore.
See IRIX Admin: Backup, Security, and Accounting for information about xfsdump and xfsrestore.
If a filesystem is damaged to the extent that you are unable to mount the filesystem successfully in the standard fashion, you may be able to recover some of its data by mounting the filesystem with the -o norecover option of the mount command. This option mounts the filesystem without running log recovery. You must mount the filesystem as read-only when you use this option.
When you mount the filesystem in norecovery mode when it was not unmounted cleanly, the filesystem is likely to be inconsistent, and you will be unable to read all of its data. However, you may be able to recover data that you can cannot otherwise access.
For information on the mount command and its options, see the mount(1M) and the fstab(4) reference pages.
If you find that your root filesystem is corrupted, you can run xfs_repair on the root filesystem itself. In order to do this, you run the xfs_repair command from the miniroot using the following procedure:
Boot the miniroot. The procedure for performing a miniroot installation is provided in IRIX Admin: Software Installation and Licensing.
From the miniroot Main Menu, select the Administrative Commands menu.
Get a single-user shell by selecting sh.
Run xfs_repair on the root filesystem, which in most cases will be /dev/dsk/dks0d1s0.