Setting up and maintaining a filesystem is a system administrative task. If you are primarily a user in your work group, read the first part of this chapter to get a general understanding of filesystems, and read the section “Backup and Recovery” so that you understand what you need to do to protect the information on your system. If you are responsible for system administration in your work group, read all of this chapter to fully understand filesystems, including setup, maintenance, backup, and recovery.
If you store paper documents in a a filing cabinet, you can choose to organize them any number of ways (for example, alphabetically, by number, or by date). The method you choose is your filing system. In much the same way, when your store information on a disk connected to your workstation, the manner in which it is stored is determined by the installed filesystem. Your Silicon Graphics system can use any of several different filesystems.
Technically speaking, a filesystem is a data structure that organizes files and directories on a disk partition so that they can be easily retrieved. Only one filesystem can reside on a disk partition (a disk always has at least one partition, and may have several).
A file is a one-dimensional array of bytes that can be in any possible order and can represent literally any information, from a memo to a three-dimensional model to an application program. Information about each file is stored in structures called inodes (inodes are described in the next section, “Inodes”). A file exists within a single filesystem.
A directory is a container that stores files and other directories. It is merely another type of file that the user is permitted to use, but not allowed to write; the operating system itself retains the responsibility for writing directories. Directories cannot span filesystems. The combination of directories and files make up a filesystem.
The starting point of any filesystem is an unnamed directory that serves as the root for that particular filesystem. In the IRIX operating system there is always one filesystem that is itself referred to by that name, the root filesystem. Traditionally, the root directory of the root filesystem is represented by a single slash (/). Filesystems are attached to the directory hierarchy by the mount command. The following illustration shows root filesystem with a mount point of a single slash (/), and two additional filesystems with mount points of /d2 and /d3, respectively
You can join two or more disk partitions to create a logical volume. The logical volume can be treated as if it were a single disk partition. A filesystem can reside on a logical volume, thus making it possible for a single filesystem to exist across more than one disk. You might create a logical volume with a single filesystem if you need to deal with very large files, or if you need to make it convenient to access a very large amount of storage space.
The following subsections describe key components of filesystems in more detail. For even greater detail, see IRIX Admin: Disks and Filesystems.
Information about each file is stored in a structure called an inode. The word inode is an abbreviation of the term index node. An inode is a data structure that stores all information about a file except its name, which is stored in the directory. Each inode has an identifying inode number, which is unique across the filesystem that includes the file.
An inode contains this information:
the type of the file (see the next section, “Types of Files,” for more information)
the access mode of the file; the mode defines the access permissions read, write, and execute and may also contain security labels and access control lists
the number of hard links to the file
who owns the file (the owner's user-ID number) and the group to which the file belongs (the group-ID number)
the size of the file in bytes
the date and time the file was last accessed and last modified
information for finding the file's data within the disk partition or logical volume
the pathname of symbolic links (when they fit and on XFS filesystems only)
You can use the ls command with various options to display the information stored in inodes. For example, the command ls -l displays all but the last two items in the list above in the order listed (the date shown is the last modified time).
Inodes do not contain the name of the file or its directory.
Filesystems can contain the file types listed in Table 2-1. You can see the type of a file in a shell window when you use the ls -l command—the first character in each line of output indicates the file's type.
Table 2-1. Filesystem File Types
File Type | Indicator | Comments |
|---|---|---|
Regular files | - | One-dimensional arrays of bytes. |
Directories | d | Containers for files and other directories. |
Symbolic links | l | Files that contain the name of another file or a directory. |
Character | c | Enable communication devices between hardware and IRIX; data is accessed on a character-by-character basis. |
Block Device | b | Enable communication between hardware and IRIX; data is accessed in blocks from a system buffer cache. |
Named pipe (also known as FIFOs) |
| Allow communication between two unrelated processes on the same host. They are created with the mknod command. |
UNIX domain sockets | s | Connections between processes that allow them to communicate, possibly over a network. |
As discussed in the section “Inodes” in this chapter, information about each file, except for the name and directory of the file, is stored in an inode for the file. The name of the file is stored in the file's directory and a link to the file is created by associating the filename with an inode number. This type of link is called a hard link. Although every file is a hard link, the term is usually used only when two or more filenames are associated with the same inode number. Because inode numbers are unique only within a filesystem, hard links cannot be created across filesystem boundaries.
The second and later hard links to a file are created with the ln command, without the -s option. For example, say the current directory contains a file called origfile. To create a hard link called linkfile to the file origfile, enter this command:
% ln origfile linkfile |
The output of ls -l for origfile and linkfile shows identical sizes and last modification times:
% ls -l origfile linkfile -rw-rw-r-- 2 joyce user 4 Apr 5 11:15 origfile -rw-rw-r-- 2 joyce user 4 Apr 5 11:15 linkfile |
Because origfile and linkfile are simply two names for the same file, changes in the contents of the file are visible when using either filename. Removing one of the links has no effect on the other. The file is not removed until there are no links to it (the number of links to the file, the link count, is stored in the file's inode).
Another type of link is the symbolic link. This type of link is actually a file. The file contains a text string, which is the pathname of another file or directory. Because a symbolic link is a file, it has its own owners and permissions. The file or directory it points to can be in another filesystem. If the file or directory that a symbolic link points to is removed, it is no longer available and the symbolic link becomes useless until the target is recreated (it is called a dangling symbolic link).
Symbolic links are created with the ln command with the -s option. For example, to create a symbolic link called linkdir to the directory origdir, enter this command:
% ln -s origdir linkdir |
The output of ls -ld for the symbolic link is shown below. Notice that the permissions and other information don't match. The listing for linkdir shows that it is a symbolic link to origdir.
% ls -ld linkdir origdir drwxrwxrwt 13 sys sys 2048 Apr 5 11:37 origdir lrwxrwxr-x 1 joyce user 8 Apr 5 11:52 linkdir -> origdir |
When you use “..” in pathnames that involve symbolic links, be aware that “ ..” refers to the parent directory of the true file or directory, not the parent of the directory that contains the symbolic link.
Filesystems don't have names per se; they are identified by their location on a disk or their position in the directory structure in these ways:
by the block and character device filenames of the disk partition or logical volume that contains the filesystem
by a mnemonic name for the disk partition or logical volume that contains the filesystem
by the mount point for the filesystem
The filesystem identifier from the list above that you use with commands that administer filesystems (such as mkfs, mount, umount, and fsck) depends upon the command. See the reference page for the command you want to use or examples in this guide to determine which filesystem name to use.
NFS filesystems are available if you are using the optional NFS software. NFS filesystems are exported from one host and mounted on other hosts across a network. The capabilities of NFS filesystems meet the needs of many work groups, and are often used in work group computing environments.
On the hosts where the filesystems reside, they are treated just like any other filesystem (for example the Extent File System™—EFS—or XFS). The only special feature of these filesystems is that they can be exported and mounted on other workstations. Exporting NFS filesystems is done with the exportfs command. On other hosts, these filesystems are mounted with the mount command or by using the automount facility of NFS.
NFS filesystems are described in detail in the ONC3/NFS Administrator's Guide , which is included with the NFS software option.
Filesystems must be mounted in order to be accessed by IRIX. The subsections below explain the use of the mount and umount commands and the file /etc/fstab to mount and unmount filesystems.
 | Tip: You can mount and unmount XFS filesystems using the graphical user interface of the xfsm command. For information, see its online help. |
The mount command is used to manually mount filesystems. The basic forms of the mount command are as shown below:
% 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.
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 this:
% mount /dev/usr /usr |
See the mount 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 starts up. 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.
For details about adding entries to /etc/fstab, and for information about the format of the /etc/fstab file, see the manual IRIX Admin: Disks and Filesystems.
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 first be exported with the exportfs command.
For complete information about setting up automounting, including all the available options, see the automount and exportfs reference pages. These commands are discussed more completely in the ONC3/NFS Administrator's Guide .
Filesystems are automatically unmounted when the system is shut down. To manually unmount filesystems, use the umount command. There are three basic forms of the command, as shown below. You can use the first two forms to unmount local filesystems, and the first and third forms to unmount remote filesystems.
% umount mount_point_directory % umount device_file % umount host:directory |
For example, to unmount a local or remote filesystem mounted at /d2, enter this command:
% umount /d2 |
To unmount the filesystem on the partition /dev/dsk/dks0d1s7, enter this command:
% umount /dev/dsk/dks0d1s7 |
To unmount the remote-mounted (NFS) filesystem depot:/usr/spool/news, enter 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. These messages and their solutions are explained in the umount reference page.
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.
If you use EFS filesystems, use fsck periodically to check the filesystems for data integrity. (XFS filesystems are checked with xfs_check only when a problem is suspected.)
Back up filesystems.
You can perform many of these functions automatically by using shell scripts. Many shell scripts are installed on your system by default. For more information, examine the scripts in /usr/lib/acct, such as ckpacct and remove, for ideas about how to build your own administration scripts.
No matter what kind of computing systems and environment you use, it is essential to regularly back up files. Backup copies are often the only way to recover files that have been accidentally erased, or lost due to hardware problems. It is the responsibility of the work group administrator to make sure there are backups of the files used in the work group. Depending on the work group's backup plan, it may be up to users or to the administrator to actually perform the backups, as well as any recovery that might be needed.
Some of the common types of backup media supported on Silicon Graphics systems include the following:
1/4” cartridge tape, 4-track
8 mm cartridge
DAT
DLT
In addition to backup devices attached to any particular system, backup devices of various types and capacities may be accessible through network connections. Refer to your owner's guide for information on locally accessible devices, and the appropriate vendor documentation for network-accessible device information.
The IRIX system provides a variety of backup tools, and you should use whichever ones work best for you. If many users at your site are already familiar with one backup program, you may wish to use that program consistently. If there are workstations at your site from other manufacturers, you may wish to use a backup utility that is common to all the workstations.
IRIX provides the following utilities for backing up your data:
System Manager, providing backup functions (this is the recommended tool if you are backing up your own filesystem).
bru, a backup tool featuring automatic file compression, space estimates, and integrity checking.
Backup and Restore, command-line front ends to the bru utility.
dump and restore, standard UNIX utilities (cannot back up XFS filesystems).
xfsdump and xfsrestore for XFS filesystems, XFS compatible versions of dump and restore.
tar, the most common UNIX backup utility (almost certainly available on workstations from other manufacturers).
cpio, a standard UNIX command (often combined in command line pipes with other commands).
dd, a standard UNIX command to read input and write output.
Optional products for Silicon Graphics systems are also available. IRIS NetWorker™ is a scalable, full-featured data management tool for data backup and recovery. You can use IRIS NetWorker to back up data on high-end servers, or centrally manage backups for all your network workstations and file servers.
For more information about backup tools, see the Personal System Administration Guide and IRIX Admin: Backup, Security, and Accounting.
As the work group administrator, you should develop a regimen for backing up the system or systems at your site and follow it closely. That way, you can accurately assess which data you can and cannot recover in the event of a mishap.
Exactly how you perform backups depends upon your workstation configuration and other factors. Regardless of the strategy you choose, though, you should always keep at least two full sets of reasonably current backups. You should also encourage users to make their own backups, particularly of critical, rapidly changing files. Users' needs can change overnight, and they know best the value of their data.
Workstation users can back up important files using the System Manager, found in the System toolchest on your screen. The System Manager is described in detail in the Personal System Administration Guide. Make sure users have access to an adequate supply of media (for example, cartridge tapes), whether new or used.
If your media can handle your largest filesystem with a single volume, you don't have to use an incremental backup scheme, though such a system reduces the amount of time you spend making backups. However, if you must regularly use multiple volumes to back up your filesystems, then an incremental backup system reduces the number of tapes you use.
The following sections discuss the different aspects of backing up data.
How often you back up your data depends upon how busy a system is and how critical the data is. A simple rule of thumb is to back up any data on the system that is irreplaceable or that someone does not want to reenter.
On most systems, the root filesystem is fairly static. You do not need to back it up as frequently as the /usr filesystem.
Changes may occur when you add software, reconfigure hardware, change the site-networking (and the system is a server or network information service [NIS] master workstation), or change some aspect of the workstation configuration. In some cases, you can maintain backups only of the individual files that change, for example, /unix, /etc/passwd, and so forth.
This process of backing up single files is not always simple. Even a minor system change such as adding a user affects files all over the system, and if you use the graphical System Manager, you may tend to forget all the files that may have changed. Also, if you are not the only administrator at the site, you may not be aware of changes made by your coworkers. Using complete filesystem backup utilities, such as the System Manager or bru, on a regular schedule avoids these problems.
A reasonable approach is to back up the root partition once a month. In addition to regular backups, here are some specific times to back up a root filesystem:
whenever you add users to the system, especially if the workstation is an NIS master workstation
just before installing new software
after installing new software and when you are certain the software is working properly
If your system is very active, or if you are not the only administrator, back up the root filesystem regularly.
The /usr filesystem, which often contains both system programs (such as in /usr/bin) and user accounts, is usually more active than a root filesystem. Therefore, you should back it up more frequently.
At a typical multiuser installation, backing up once per day, using an incremental scheme, should be sufficient.
Treat the /var filesystem similarly —it contains data such as the contents of users' mailboxes.
Incremental backups can use fewer tapes to provide the same level of protection as repeatedly backing up the entire filesystem. They are also faster than backing up every file on the system.
An incremental scheme for a particular filesystem looks something like this:
On the first day, back up the entire filesystem. This is a monthly backup.
On the second through seventh days, back up only the files that changed from the previous day. These are daily backups.
On the eighth day, back up all the files that changed the previous week. This is a weekly backup.
Repeat steps 2 and 3 for four weeks (about one month).
After four weeks (about a month), start over, repeating steps 1 through 4.
You can recycle daily tapes every month, or whenever you feel safe about doing so. You can keep the weekly tapes for a few months. You should keep the monthly tapes for about one year before recycling them.
If you are managing a site with many networked workstations, you may wish to save backups on a device located on a central workstation.
To back up across a network, use the same basic backup commands, but with a slight change. Enter:
% system_name:/dev/tape |
If required, specify an account on the remote device:
% user@system_name:/dev/tape |
Users can use a central tape drive from their workstations with this method. Note that if you are backing up to a remote tape drive on a workstation that is not made by Silicon Graphics, the device name /dev/tape may not be the correct name for the tape drive. Always learn the pathname of the tape device before executing the backup commands.
For example:
% tar cvf guest@alice:/dev/tape ./bus.schedule |
or
% echo “./bus.schedule” | cpio -ovcO guest@alice:/dev/tape |
You can use the cron utility to automatically back up filesystems at predetermined times. The backup media must be already mounted in the drive, and, if you want this to be truly automatic, it should have enough capacity to store all the data being backed up on a single piece of media. If all the data doesn't fit, then someone must manually change backup media.
Here is an example cron command to back up the /usr/src hierarchy to /dev/tape (tape drive) every morning at 03:00 using bru:
0 3 * * * /usr/sbin/bru -c -f /dev/tape /usr/src |
Place this line in a crontabs file, such as /var/spool/cron/crontabs/root.
This sort of command is useful as a safety net, but you should not rely solely on automatic backups. There is no substitute for having a person monitor the backup process from start to finish and properly archive and label the media when the backup is finished. For more information on using cron to perform jobs automatically, see IRIX Admin: System Configuration and Operation.
Store your backup tapes carefully. Even if you create backups on more durable media, such as optical disks, take care not to abuse them. Set the write protect switch on tapes you plan to store as soon as a tape is written, but remember to unset it when you are ready to overwrite a previously-used tape.
Do not subject backups to extremes of temperature and humidity, and keep tapes away from strong electromagnetic fields. If there are a large number of workstations at your site, you may wish to devote a special room to storing backups.
Store magnetic tapes, including 1/4” and 8 mm cartridges, upright. Do not store tapes on their sides, as this can deform the tape material and cause the tapes to read incorrectly.
Make sure the media is clearly labeled and, if applicable, write-protected. Choose a label-color scheme to identify such aspects of the backup as what system it is from, what level of backup (complete versus partial), what filesystem, and so forth.
To minimize the impact of a disaster at your site, such as a fire, you may want to store main copies of backups in a different building from the actual workstations. You have to balance this practice, though, with the need to have backups handy for recovering files.
If backups contain sensitive data, take the appropriate security precautions, such as placing them in a locked, secure room. Anyone can read a backup tape on a system that has the appropriate utilities.
You can keep backups as long as you think you need to. In practice, few sites keep system backup tapes longer than about a year before recycling the tape for new backups. Usually, data for specific purposes and projects is backed up at specific project milestones (for example, when a project is started or finished). As site administrator, you should consult with your users to determine how long to keep filesystem backups.
With magnetic tapes, however, there are certain physical limitations. Tape gradually loses its flux (magnetism) over time. After about two years, tape can start to lose data.
For long-term storage, re-copy magnetic tapes every year to year-and-a-half to prevent data loss through deterioration. When possible, use checksum programs, such as the sum utility, to make sure data hasn't deteriorated or altered in the copying process. If you want to store data reliably for several years, consider using optical disk.
You can reuse tapes, but with wear, the quality of a tape degrades. The more important the data, the more precautions you should take, including using new tapes.
If a tape goes bad, mark it as “bad” and discard it. Write “bad” on the tape case before you throw it out so that someone doesn't accidentally try to use it. Never try to reuse an obviously bad tape. The cost of a new tape is minimal compared to the value of the data you are storing on it.
To make a backup of your system on any system with a graphical user interface, bring up the System menu on the System Toolchest and select the Backup & Restore menu item. From the Backup & Restore window, follow the prompts to perform your backup. A complete set of instructions for this procedure is available in the Personal System Administration Guide.
Backups made with the Backup & Restore window are the easiest to make and use, and are accessible from the Recover System option on the System Maintenance Menu if they are full system backups. When you make a full system backup, the command also makes a backup of the files in the disk volume header and saves the information in a file that is stored on tape. This file is used during system recovery to restore a damaged volume header.
To make a backup of your system using an IRIX command, use the Backup command. Although the Backup command is a front-end interface to the bru command, Backup also writes the disk volume header on the tape so that the Recover System option can reconstruct the boot blocks, which are not written to the tape using other backup commands.
Follow these steps when making a backup, no matter which backup utility you use:
Make sure the tape drive is clean. The hardware manual that came with your drive should state how, and how often, to clean the drive.
Dirty tape heads can cause read and write errors. New tapes shed more oxide than older tapes, so you should clean your drive more frequently if you use a lot of new tapes.
Make sure you have enough backup media on hand. The bru utility has an option to check the size of a backup, so you can determine if you have enough media. You can also use such utilities as du and df to determine the size of directories and filesystems, respectively.
Also, use good-quality media. Considering the value of your data, use the best quality media you can afford.
Run fsck first on EFS filesystems (if you are backing up an entire filesystem) to make sure you do not create a tape of a damaged filesystem. You must unmount a filesystem before checking it with fsck, so plan your backup schedule accordingly.
This step is not necessary if you are backing up only a few files (for example, with tar).
The default tape device for any drives you may have is /dev/tape. If you do not use the default device, you must specify a device in your backup command line.
Label your backups. If you plan to reuse the media, use pencil. Include the date, time, name of the system, the name of the utility, the exact command line used to make the backup (so you'll remember how to extract the files later), and a general indication of the contents. If more than one administrator performs backups at your site, include your name.
Verify the backup when you are finished. Some utilities (such as dump and bru) provide explicit options to verify a backup. With other programs, you can simply list the contents of the archive—this is usually sufficient to catch errors in the backup.
Write-protect your media after you make the backup.
Note the number of times you use each tape. Keep a running tally on the tape label.