How File System Commands Determine the File System Type

The generic file system commands determine the file system type by following this sequence:

1. From the -F option, if supplied.

2. By matching a special device with an entry in the /etc/vfstab file (if special is supplied). For example, fsck first looks for a match against the fsck device field. If no match is found, it then checks the special device field.

3. By using the default specified in the /etc/default/fs file for local file systems and in the /etc/dfs/fstypes file for remote file systems.

Manual Pages for Generic and Specific Commands

Both the generic commands and specific commands have manual pages in the man Pages(1M): System Administration Commands. The manual page for the generic file system commands provide information about generic command options only. The manual page for a specific file system command has specific information about options for that file system. To look at a specific manual page, append an underscore and the abbreviation for the file system type to the generic command name. For example, to see the specific manual page for mounting a UFS file system, type the following:

$ man mount_ufs

The Default Solaris File Systems

The Solaris UFS file system is hierarchical, starting with the root directory (/) and continuing downwards through a number of directories. The Solaris installation process enables you to install a default set of directories and uses a set of conventions to group similar types of files together. The following table provides a summary of the default Solaris file systems.

Table 38-2 The Default Solaris File Systems

The root (/) and /usr file systems are needed to run a system. Some of the most basic commands in the /usr file system (like mount) are included in the root (/) file system so that they are available when the system boots or is in single-user mode and /usr is not mounted. For more detailed information on the default directories for the root (/) and /usr file systems, see Chapter 44, UFS File System (Reference).

Swap Space

The Solaris operating system uses some disk slices for temporary storage rather than for file systems. These slices are called swap slices, or swap space. Swap space is used as virtual memory storage areas when the system does not have enough physical memory to handle current processes.

Since many applications rely on swap space, you should know how to plan for, monitor, and add more swap space when needed. For an overview about swap space and instructions for adding swap space, see Chapter 42, Configuring Additional Swap Space (Tasks).

The UFS File System

UFS is the default disk-based file system in Solaris operating system. Most often, when you administer a disk-based file system, you will be administering UFS file systems. UFS provides the following features:

For detailed information about the UFS file system structure, see Chapter 44, UFS File System (Reference).

UFS Logging

UFS logging bundles the multiple metadata changes that make up a complete UFS operation into a transaction. Sets of transactions are recorded in an on-disk log, and then applied to the actual UFS file system's metadata.

At reboot, the system discards incomplete transactions, but applies the transactions for completed operations. The file system remains consistent because only completed transactions are ever applied. This consistency remains even when a system crashes, which normally interrupts system calls and introduces inconsistencies into a UFS file system.

UFS logging provides two advantages:

• If the file system is already consistent due to the transaction log, you might not have to run the fsck command after a system crash or an unclean shutdown. For more information on unclean shutdowns, see What the fsck Command Checks and Tries to Repair.

• Can often provide a significant performance improvement because a file system with logging enabled converts multiple updates to the same data into single updates, and so reduces the number of overhead disk operations required.

The log is allocated from free blocks on the file system, and it is sized at approximately 1 Mbyte per 1 Gbyte of file system, up to a maximum of 64 Mbytes. The log is continually flushed as it fills up. The log is also flushed when the file system is unmounted or as a result of any lockfs command.

UFS logging is enabled by default on file systems greater than 1 terabyte in size.

If you need to enable UFS logging, specify the -o logging option with the mount command in the /etc/vfstab file or when you mount the file system manually. Logging can be enabled on any UFS file system. Also, the fsdb command now has new debugging commands to support UFS logging.

In some operating systems, a file system with logging enabled is known as a journaling file system.

Planning UFS File Systems

When laying out file systems, you need to consider possible conflicting demands. Here are some suggestions:

• Distribute the work load as evenly as possible among different I/O systems and disk drives. Distribute the /export/home file system and swap space evenly across disks.

• Keep pieces of projects or members of groups within the same file system.

• Use as few file systems per disk as possible. On the system (or boot) disk, you should have three file systems: root (/), /usr, and swap space. On other disks, create one or, at most, two file systems; one being additional swap space, preferably. Fewer, roomier file systems cause less file fragmentation than many small, over-crowded file systems. Higher-capacity tape drives and the ability of the ufsdump command to handle multiple volumes make it easier to back up larger file systems.

• If you have some users who consistently create very small files, consider creating a separate file system with more inodes. However, most sites do not need to keep similar types of user files in the same file system.

For information on default file system parameters as well as procedures for creating new UFS file systems, see Chapter 39, Creating File Systems (Tasks).

UFS Direct Input/Output (I/O)

Direct I/O is intended to boost bulk I/O operations. Bulk I/O operations use large buffer sizes to transfer large files (larger than 256 Kbytes).

Using UFS direct I/O might benefit applications, such as database engines, that do their own internal buffering. Starting with the Solaris 8 1/01 release, UFS direct I/O has been enhanced to allow the same kind of I/O concurrency seen when accessing raw devices. Now you can get the benefit of file system naming and flexibility with very little performance penalty. Check with your database vendor to see if they can enable UFS direct I/O in their product configuration options.

Direct I/O can also be enabled on a file system by using the forcedirectio option to the mount command. Enabling direct I/O is a performance benefit only when a file system is transferring large amounts of sequential data.

When a file system is mounted with this option, data is transferred directly between a user's address space and the disk. When forced direct I/O is not enabled for a file system, data transferred between a user's address space and the disk is first buffered in the kernel address space.

The default behavior is no forced direct I/O on a UFS file system. For more information, see mount_ufs(1M).

Mounting and Unmounting File Systems

Before you can access the files on a file system, you need to mount the file system. When you mount a file system, you attach that file system to a directory (mount point) and make it available to the system. The root (/) file system is always mounted. Any other file system can be connected or disconnected from the root (/) file system.

When you mount a file system, any files or directories in the underlying mount point directory are unavailable as long as the file system is mounted. These files are not permanently affected by the mounting process, and they become available again when the file system is unmounted. However, mount directories are typically empty, because you usually do not want to obscure existing files.

For example, the following figure shows a local file system, starting with a root (/) file system and the sbin, etc, and opt subdirectories.

Figure 38-1 Sample root (/) File System

To access a local file system from the /opt file system that contains a set of unbundled products, you must do the following:

• First, you must create a directory to use as a mount point for the file system you want to mount, for example, /opt/unbundled.

• Once the mount point is created, you can mount the file system (by using the mount command), which makes all of the files and directories in /opt/unbundled available, as shown in the following figure.

For step-by-step instructions on how to mount file systems, see Chapter 40, Mounting and Unmounting File Systems (Tasks).

Figure 38-2 Mounting a File System