This chapter explains some important concepts about hard disk filesystems, the structure by which files and directories are organized in the IRIX system. The chapter describes the primary type of IRIX filesystem, the XFS filesystem, and other disk filesystems. It explains concepts that are important to filesystem administration such as IRIX directory organization, filesystem features, filesystem types, creating filesystems, mounting and unmounting filesystems, and checking filesystems for consistency.
 | Note: For information on CXFS filesystems and the cluster environment they support, see the CXFS Software Installation and Administration Guide. |
The major sections in this chapter are:
Even if you are familiar with the basic concepts of UNIX filesystems, you should read through the following sections. The IRIX XFS filesystem is slightly different internally from other UNIX filesystems and has slightly different administration commands and procedures.
Filesystem administration procedures are described in Chapter 6, “Creating and Growing Filesystems”, and Chapter 7, “Maintaining Filesystems”.
For information about floppy and CD-ROM filesystems, see the guide
Every IRIX system disk contains some standard directories. These directories contain operating system files organized by function. This organization is not entirely logical; it has evolved over time and has its roots in several versions of UNIX. Table 5-1 lists the standard directories that most systems have. It also lists alternate names for those directories in some cases. The alternate names are usually an older pathname for the directory and are provided (as symbolic links) to ease the transition from old pathnames to new pathnames as the IRIX directory organization evolves.
Table 5-1. Standard Directories and Their Contents
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 file is a one-dimensional array of bytes with no other structure implied. Information about each file is stored in structures called inodes (inodes are described in “Inodes”). Files cannot span filesystems.
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 result is the IRIX directory structure shown in Figure 5-1.
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, so a filesystem can reside on a logical volume and hence is the only way for a single filesystem to span more than one disk. For more information on XLV logical volumes, see Chapter 3, “XLV Logical Volume Concepts”.
The following subsections describe key components of 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 the following information:
The type of the file (see “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 (see “Hard Links and Symbolic Links” for more information)
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 types of files listed Table 5-2. The type of a file is indicated by the first character in the line of ls -l output for the file.
As discussed in “Inodes”, 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, suppose 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 (see Table 5-2). 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:
% ln -s origdir linkdir |
The output of ls -ld for the symbolic link is shown below. Notice that the permissions and other information do not 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.
For more information about hard and symbolic links, see the ln(1) reference page and experiment with creating and removing hard and symbolic links.
Filesystems do not have names per se; they are identified by their location on a disk or their position in the directory structure as follows:
By the block and character device file names of the disk partition or logical volume that contains the filesystem (see “Block and Character Devices” in Chapter 1)
By a mnemonic name for the disk partition or logical volume that contains the filesystem (see “Creating Mnemonic Names for Device Files With ln” in Chapter 2)
By the mount point for the filesystem (see “Filesystem Mounting and Unmounting”)
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.
XFS is an IRIX filesystem designed for use on most Silicon Graphics systems—from desktop systems to supercomputer systems. Its major features include:
Full 64-bit file capabilities (files larger than 2 GB)
Rapid and reliable recovery after system crashes because of journaling technology
Efficient support of large, sparse files (files with “holes”)
Integrated, full-function volume manager, the XLV Volume Manager
Extremely high I/O performance that scales well on multiprocessing systems
Guaranteed-rate I/O for multimedia and data acquisition uses
Compatibility with existing applications and with NFS
User-specified filesystem block sizes ranging from 512 bytes up to 64 KB
Small directories and symbolic links of 156 characters or less take no space
At least 32 MB of memory is recommended for systems with XFS filesystems.
XFS supports files and filesystems of 240-1 or 1,099,511,627,775 bytes (one terabyte) on 32-bit systems (IP17, IP20, IP22, and IP32). Files up to 263-1 bytes and filesystems of unlimited size are supported on 64-bit systems (IP19, IP21, IP25, IP26, and IP27). You can use the filesystem interfaces supplied with the IRIS Development Option (IDO) software option to write 32-bit programs that can track 64-bit position and file size. Many programs work without modification because sequential reads succeed even on files larger than 2 GB. NFS allows you to export 64-bit XFS filesystems to other systems.
XFS uses database journaling technology to provide high reliability and rapid recovery. Recovery after a system crash is completed within a few seconds, without the use of a filesystem checker such as the fsck command. Recovery time is independent of filesystem size.
XFS is designed to be a very high performance filesystem. Under certain conditions, throughput exceeds 100 MB per second. Its performance scales to complement the CHALLENGE MP architecture and the ORIGIN 2000 architecture. While traditional filesystems suffer from reduced performance as they grow in size, with XFS there is no performance penalty.
You can create filesystems with block sizes ranging from 512 bytes to 64 KB. For real-time data, the maximum extent size is 1 GB. Filesystem extents, which provide for contiguous data within a file, are created automatically for normal files and may be configured at file creation time for real-time files using the fcntl() system call. Extents are multiples of a filesystem block. Inodes are created as needed by XFS filesystems. You can specify the size of inodes with the -i option to the filesystem creation command, mkfs. You can also specify the maximum percentage of the space in a filesystem that can be occupied by inodes with the -i maxpct= option of the mkfs command.
A feature of XFS filesystems called extended attributes enables users and applications to associate name and value pairs to files, directories, symbolic links, and inodes. These name and value pairs are called attributes and can be set and displayed with the attr command. For more information see the, attr(1) reference page.
Two features of XFS filesystems enable applications to control their I/O bandwidth allocation. Guaranteed-rate I/O, described in Chapter 8, “System Administration for Guaranteed-Rate I/O”, enables a process to receive data from a system resource at a predefined rate, regardless of other activity on the system. Priority I/O, described in the prio(5) reference page, enables a process to reserve a portion of the system's resources for its exclusive use for a period of time.
Most filesystem commands, such as du, dvhtool, ls, mount, prtvtoc, and umount, work with XFS filesystems with no user-visible changes. A few commands, such as df, fx, and mkfs have additional features for XFS. The filesystem commands clri, fsck, findblk, and ncheck are not used with XFS filesystems.
For backup and restore, use the standard IRIX commands backup, bru, cpio, restore, and tar and the optional software product NetWorker for IRIX for files smaller than 2 GB. To dump XFS filesystems, the command xfsdump must be used instead of dump. Restoring from these dumps is done using xfsrestore. For more information about the relationships between xfsdump, xfsrestore, dump, and restore on XFS filesystems, see the “About xfsdump and xfsrestore” section of the “Backup and Recovery Procedures” chapter of IRIX Admin: Backup, Security, and Accounting.
CXFS is a clustered XFS filesystem that allows for logical file sharing, as with networked filesystems, but with significant performance and functionality advantages.CXFS runs on top of a storage area network (SAN), where each computer system in the cluster has direct high-speed data channels to a shared set of disks. Running CXFS requires a FLEXlm license key.
For information about the features of CXFS filesystems as well as information about installing and administering CXFS filesystems, see the CXFS Software Installation and Administration Guide.
| Note: Support for EFS filesystems will be discontinued in a future IRIX release. For information on converting EFS filesystems to XFS filesystems, see Chapter 6, “Creating and Growing Filesystems”. |
The EFS filesystem is the original IRIX filesystem. It contains an enhancement to the standard UNIX filesystem called extents, and thus is called the Extent File System (EFS). The maximum size of an EFS filesystem is about 8 GB. It uses a filesystem block size of 512 bytes and allows a maximum file size of 2 GB minus 1 byte.
Information on EFS filesystems and their administration is provided in Appendix A, “EFS Filesystems”.
NFS filesystems are available if you are using the optional NFS software. NFS filesystems are filesystems that are exported from one host and mounted on other hosts across a network.
On the hosts where the filesystems reside, they are treated just like any other XFS filesystem. The only special feature of these filesystems is that they are exported for mounting from 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.
 | Tip: The section “Making Your Disk Space Available to Other Users” in Chapter 4 of the Personal System Administration Guide and the section “Using Disk Space on Other Systems” in Chapter 5 of the Personal System Administration Guide provide instructions for mounting and exporting NFS filesystems. |
NFS filesystems are described in detail in the ONC3/NFS Administrator's Guide , which is included with the NFS software option.
The Cache File System (CacheFS) is a new filesystem type that provides client-side caching for NFS and other filesystem types. Using CacheFS on NFS clients with local disk space can significantly increase the number of clients a server can support and reduce the data access time for clients using read-only file systems.
The cfsadmin command is used for managing CacheFS filesystems. A special version of the fsck command, fsck_cachefs is used to check the integrity of a cache directory. It is automatically invoked when a CacheFS filesystem is mounted. When mounting and unmounting CacheFS filesystems, the -t cachefs option must be used. For more information on these commands, see the cfsadmin(1M), fsck_cachefs(1M), and mount(1M) reference pages.
CacheFS filesystems are available if you are using the optional NFS software. They are described in detail in the ONC3/NFS Administrator's Guide , which is included with the NFS software option.
The /proc filesystem, also known as the debug filesystem, provides an interface to running IRIX processes for use by monitoring programs, such as ps and top, and debuggers, such as dbx. The debug filesystem is usually mounted on /proc with a link to /debug. To reduce confusion, /proc is not displayed when you list free space with the df command.
The “files” of the debug filesystem are of the form /proc/nnnnn and /proc/pinfo/nnnnn, where nnnnn is a decimal number corresponding to a process ID. These files do not consume disk space; they are merely handles for debugging processes. /proc files cannot be removed.
See the proc(4) reference page for more information on the debug filesystem.
The hardware graph, also known as the hwgraph, is a feature of IRIX that facilitates the management of large and topologically complex I/O subsystems. The /hw filesystem is a visible reflection of the hwgraph. The /hw filesystem is a filesystem type, similar to /proc. Like /proc, /hw is not displayed when you list free space with the df command.
| Note: The contents of the hardware graph and the links in it may change across hardware and software releases. For this reason, an administrator should use the /dev directory as the root of the path for all device file usage, even though the directories under /dev are links into /hw. For example, you should not use device names under /hw when mounting filesystems or configuring the root filesystem. |
The hwgraph is a directed graph, consisting of a set of “vertexes” (points) that represent hardware entities and “edges” (lines) that connect the vertexes. Each edge is a one-way linkage from a source vertex to a target vertex (this is the definition of a directed graph). Each edge has a label, a character string that names the edge. A small part of a typical hwgraph is depicted in Figure 5-2.
Figure 5-2 shows the part of the graph that represents block and character access to the whole-volume partition of a disk. Pathname notation is used to identify each hardware entity (vertex). The pathname consists of each of the edges in the path from the root to the hardware entity. For example, the two paths to each of the block and character devices might be:
/hw/module/1/io/pci/slot/0/scsi_ctlr/0/target/1/lun/0/disk/volume/block /hw/module/1/io/pci/slot/0/scsi_ctlr/0/target/1/lun/0/disk/volume/char /hw/module/1/io/dks0d0vol/block /hw/module/1/io/dks0d0vol/char |
The hwgraph is built dynamically (it has no on-disk contents) and changes to reflect changes in the hardware inventory. Figure 5-2 is color-coded to show the parts of graph are built by the kernel (black), the PCI bus adapter (red), the SCSI controller driver (magenta), and the disk device driver (green). In the hwgraph, logical controller numbers are used for each controller in the I/O subsystem, rather than physical controller numbers. These logical controller numbers are specified in the file /etc/ioconfig.conf. For more information, see the ioconfig(1M) reference page. The ioconfig(1M) reference page also describes the configuration file /etc/ioperms, which contains information about the owner, group, and permissions of devices in the hwgraph.
You can navigate the /hw filesystem using commands such as cd, ls, and find and browse it to discover the hardware configuration. Symbolic links to /hw paths exist to all the device special filenames that are conventionally expected to exist in /dev, with the exception of XLV logical volumes. The symbolic links are implemented by creating them from /dev to /hw. Here is a typical link:
lrwxr-xr-x 1 root sys 13 Aug 6 11:23 /dev/root -> /hw/disk/root |
Do not remove /hw; very little on the system works without it.
The IRIX operating system supports four filesystem formats native to other operating systems. These filesystem formats are as follows:
For further information on the filesystem types that IRIX supports, see the filesystems(4) reference page. For information on administering hfs and dos filesystems, see the mkfp(1M) and fpck(1M) reference pages.
To turn a disk partition or logical volume into an XFS filesystem, the mkfs command must be used. It takes a disk partition or logical volume and divides it up into areas for data blocks, inodes, and free lists, and writes out the appropriate inode tables, superblocks, and block maps. It creates the filesystem's root directory.
The following mkfs example makes an XFS filesystem with a 1 MB internal log section is:
# mkfs -l size=1m /dev/rdsk/dks0d2s7 |
The following mkfs example makes an XFS filesystem on a logical volume with log and data subvolumes is:
# mkfs /dev/rxlv/a |
For more instructions on making XFS filesystems see Chapter 6, “Creating and Growing Filesystems”, and the mkfs(1M) and mkfs_xfs(1M) reference pages.
Filesystems must be mounted to be used. Figure 5-3 illustrates this process. When a filesystem is mounted, the name of the device file for the filesystem (/dev/rdsk/dks0d2s7 in Figure 5-3) and the name of a directory (/proj in Figure 5-3) are given. This directory, /proj,is called a mount point and forms the connection between the filesystem containing the mount point and the filesystem to be mounted. Mounting a filesystem tells the kernel that the mount point is to be considered equivalent to the top level directory of the filesystem when pathnames are resolved. In Figure 5-3, the files a, b, and c in the /dev/rdsk/dks0d2s7 filesystem become /proj/a, /proj/b, and /proj/c as shown in the bottom of the figure.
When you mount a filesystem, the original contents of the mount point directory are hidden and unavailable until the filesystem is unmounted. However, the mount point directory owner and permissions are not hidden. Restricted permissions can restrict access to the mounted filesystem.
Unlike other filesystems, the root filesystem (/) is mounted as soon as the kernel is running and cannot be unmounted because it is required for system operation. The usr filesystem, if it is a separate filesystem from the root filesystem, must also be mounted for the system to operate properly. System administration that requires unmounting the root and usr filesystem can be done in the miniroot. See “XFS Filesystem Checking” for more information.
You can mount filesystems in several ways:
Manually with the mount command (see “Manually Mounting Filesystems” in Chapter 7)
Automatically when the system is booted, using information in the file /etc/fstab (see “Mounting Filesystems Automatically With the /etc/fstab File” in Chapter 7)
Automatically when the filesystem is accessed (called automounting, which applies to NFS (remote) filesystems only; see “Mounting a Remote Filesystem Automatically ” in Chapter 7)
Automatically when a removable disk is inserted (see the mediad(1M) reference page for information on the daemon that monitors removable media devices)
You can unmount filesystems in two ways:
Shut down the system (filesystems are unmounted automatically)
Manually unmount filesystems with the umount command (see the section “Unmounting Filesystems” in Chapter 7)
The mount and umount commands are described in detail in “Mounting and Unmounting Filesystems” in Chapter 7.
The xfs_check command checks XFS filesystem consistency. It is normally used only when a filesystem consistency problem is suspected. See the xfs_check(1M) reference page for more information.
Filesystems can become fragmented over time. When a filesystem is fragmented, blocks of free space are small and files have many extents. The fsr command reorganizes filesystems so that the layout of the extents is improved. This improves overall performance.
By default, fsr is run automatically once a week from crontab. If the fsr command determines that a mounted filesystem is an XFS filesystem, the command calls the fsr_xfs command. See the fsr(1M) reference page for information on the fsr command, and the fsr_xfs(1M) man page for information on the fsr_xfs options for the command.
When filesystem modifications or other administrative tasks require that the root filesystem not be mounted or not be in use, the miniroot environment provided by the software installation tools included on IRIX system software release CDs can be used. When using the miniroot, a limited version of IRIX is installed in the swap partition in a filesystem mounted at /. The system runs this version of IRIX rather than the standard IRIX in the root and usr filesystems. The root and usr filesystems are available and mounted at /root and /root/usr. Thus the pathnames of all files in the root and usr filesystems have the prefix /root.
You can add filesystem space in three ways:
Add a new disk, create a filesystem on it, and mount it as a subdirectory on an existing filesystem.
Change the size of the existing filesystems by removing space from one partition and adding it to another partition on the same disk.
Add another disk and grow an existing XFS filesystem onto that disk with the xfs_growfs command.
These three methods of adding filesystem space are discussed in the following subsections.
To mount a filesystem as a subdirectory, you simply add a new disk with a separate filesystem and create a new mount point for it within your filesystem. This is generally considered the safest way to add space. For example, if your usr filesystem is short of space, add a new disk and mount the new filesystem on a directory called /usr/work. A drawback of this approach is that it does not allow hard links to be created between the original filesystem and the new filesystem.
See Chapter 2, “Performing Disk Administration Procedures”, for full information on partitioning a disk and making filesystems on it.
To move disk space from one filesystem on a disk to another filesystem on the same disk, you must back up your existing data on both filesystems; run the fx command to repartition the disk; then remake both filesystems with the mkfs command. This method has serious drawbacks. It is a great deal of work and has certain risks. For example, to increase the size of a filesystem, you must remove space from other filesystems. You must be sure that when you finish changing the size of your filesystems, your old data still fits on all the new, smaller filesystems. Also, resizing your filesystems may at best be a stop-gap measure until you can acquire additional disk space.
Repartitioning is documented in “Repartitioning a Disk With fx” in Chapter 2. For additional solutions when the filesystem is the root filesystem, see “Running Out of Space in the Root Filesystem ” in Chapter 7.
Growing an existing filesystem onto an additional disk or disk partition is another way to increase the available space in that filesystem. The original disk partition and the new disk partition become a logical volume. The xfs_growfs command preserves the existing data on the hard disk and adds space from the new disk partition to the filesystem. This process is simpler than completely remaking your filesystems. The one drawback to growing a filesystem across disks is that if one disk fails, you may not recover data from the other disk, even if the other disk still works. If your usr filesystem is a logical volume, you will be unable to boot the system into multiuser mode. For this reason, it is preferable, if possible, to mount an additional disk and filesystem as a directory on the root or usr filesystems (on / or /usr).
For instructions on growing a filesystem onto an additional disk, see “Growing an XFS Filesystem Onto Another Disk” in Chapter 6.
If your system is constantly short of disk space and you cannot increase the amount of available space, you may be forced to implement disk quotas. Quotas allow you to limit the amount of space a user can occupy and the number of files (inodes) each user can own. IRIX provides disk quotas to automate this process. You can use this system to implement specific disk usage quotas for each user on your system. You can implement hard or soft limits; hard limits are enforced by the system, soft limits merely remind the user to trim disk usage. Disk usage limits are not enforced for root.
With soft limits, whenever a user logs in with a usage greater than the assigned soft limit, that user is warned (by the login command). When the user exceeds the soft limit, the timer is enabled. Any time the quota drops below the soft limits, the timer is disabled. If the timer is enabled longer than a time period set by the system administrator, the particular limit that has been exceeded is treated as if the hard limit has been reached, and no more disk space is allocated to the user. The only way to reset this condition is to reduce usage below the quota. Only root may set the time limits, and this is done on a per-filesystem basis.
Several options are available on XFS filesystems. You can impose limits on some users and not others, some filesystems and not others, and on total disk usage per user, or total number of files. In addition, on XFS filesystems there is no limit to the number of accounts and there is little performance penalty for large numbers of users.
On XFS filesystems, you can also impose limits according to project IDs or group IDs as well as user IDs. Quotas based on project IDs and quotas based on group IDs are mutually exclusive. For information on project and group IDs and how they are established, see IRIX Admin: Backup, Security, and Accounting. For information on using disk quotas for project or group IDS, see “Using Disk Quotas on XFS Filesystems” in Chapter 7.
Disk quotas on XFS filesystems can be used to do disk usage accounting. Disk usage accounting monitors disk usage, but does not enforce disk usage limits. See “Identifying Accounts That Use Large Amounts of Disk Space” in Chapter 7 for more information.
Disk quotas are described in more detail in the quotas(4) reference page. Procedures for imposing and monitoring disk quotas are described in “Using Disk Quotas on XFS Filesystems” in Chapter 7.
Most often, a filesystem is corrupted because the system experienced a panic or did not shut down cleanly. This can be caused by system software failure, hardware failure, or human error (for example, pulling the plug). Another possible source of filesystem corruption is overlapping partitions.
There is no foolproof way to predict hardware failure. The best way to avoid hardware failures is to conscientiously follow recommended diagnostic and maintenance procedures.
Human error is probably the greatest single cause of filesystem corruption. To avoid problems, follow these rules closely:
Always shut down the system properly. Do not simply turn off power to the system. Use a standard system shutdown tool, such as the shutdown command.
Never remove a filesystem physically (pull out a hard disk) without first turning off power.
Never physically write-protect a mounted filesystem, unless it is mounted read-only.
Do not mount filesystems on dual-hosted disks on two systems simultaneously.
The best way to insure against data loss is to make regular, careful backups. See IRIX Admin: Backup, Security, and Accounting for complete information on system backups.
In some cases, XFS filesystem corruption, even on the root file system, can be repaired with the command xfs_repair. For more information about xfs_repair see “Checking XFS Filesystem Consistency With xfs_check and xfs_repair ” in Chapter 7.