System Administration Guide: Basic Administration

Chapter 37 Managing File Systems (Overview)

The management of file systems is one of your most important system administration tasks.

This is a list of the overview information in this chapter.

What's New in File Systems?

This section describes new file system features in the Solaris 9 release.

Extended File Attributes

The UFS, NFS, and TMPFS file systems have been enhanced to include extended file attributes, which enable application developers to associate specific attributes to a file. For example, a developer of a windowing system file management application might choose to associate a display icon with a file. Extended file attributes are logically represented as files within a hidden directory that is associated with the target file.

You can use the runat command to add attributes and execute shell commands in the extended attribute name space, which is a hidden attribute directory that is associated with the specified file.

To use the runat command to add attributes to a file, you first have to create the attributes file.

$ runat filea cp /tmp/attrdata attr.1

Then, use the runat command to list the attributes of a file.

$ runat filea ls -l

For more information, see the runat(1) man page.

Many Solaris file system commands have been modified to support file system attributes by providing an attribute-aware option that you can use to query, copy, or find file attributes. For more information, see the specific man page for each file system command.

UFS Snapshots

You can use the fssnap command to create a read-only snapshot of a file system. A snapshot is a file system's temporary image that is intended for backup operations.

See Chapter 47, Using UFS Snapshots (Tasks) for more information.

Improved UFS Direct I/O Concurrency

The performance of direct I/O, which is used by database applications to access unbuffered file system data, has been improved by allowing concurrent read and write access to regular UFS files. Previously, an operation that updated file data would lock out all other read or write accesses until the update operation was completed.

Concurrent writes are restricted to the special case of file rewrites. If the file is being extended, writing is single threaded as before. Generally, databases pre-allocate files and seldomly extend them thereafter. Therefore, the effects of this enhancement are evident during normal database operations.

The direct I/O improvements brings I/O bound database performance on a UFS file system to about 90% of raw partition access speeds. If the database is CPU bound or bus bandwidth bound, there might be no improvement.

Consider running your I/O database applications with direct I/O enabled if you are already using UFS to store database tables. Use your database administrative procedures to enable direct I/O, if possible. If there is no way to enable direct I/O through your database product, use the mount -forcedirectio option to enable direct I/O for each file system. Or, use the directio(3C) library call to enable direct I/O.

See mount_ufs(1M) or directio(3C) for more information.

Improved mkfs Performance

The mkfs command now has improve performance when you create file systems. Improved mkfs performance is often 10 times faster than in previous Solaris releases. Performance improvements occur on systems when you create both large and small file systems. However, the biggest performance improvements occur when creating file systems on systems with high-capacity disks or high-speed disks.

New labelit Options for UDF File Systems

The labelit command provides new options for use with Universal Disk Format (UDF) file systems. You can use the new labelit command options to identify the author name, organization, and contact information for a UDF volume.

There was no mechanism to update this information, which is part of general UDF file systems, in previous Solaris releases.

The new UDF specific options for the labelit command, specified with the -o option, are the following:

The maximum length for each option is 35 bytes.

For more information, see labelit_udfs(1M).

Where to Find File System Management Tasks

Use these references to find step-by-step instructions for the management of file systems.

File System Management Task 

For More Information 

Create new file systems 

Chapter 38, Creating File Systems (Tasks) and Chapter 40, Using The CacheFS File System (Tasks)

Make local and remote files available to users 

Chapter 39, Mounting and Unmounting File Systems (Tasks)

Connect and configure new disk devices 

Chapter 31, Managing Disks (Overview)

Design and implement a backup schedule and restoring files and file systems, as needed 

Chapter 45, Backing Up and Restoring File Systems (Overview)

Check for and correct file system inconsistencies 

Chapter 42, Checking UFS File System Consistency (Tasks)

Overview of File Systems

A file system is a structure of directories that is used to organize and store files. The term file system is used to describe the following:

Usually, you can tell from the context which meaning is intended.

The Solaris operating environment uses the virtual file system (VFS) architecture, which provides a standard interface for different file system types. The VFS architecture enables the kernel to handle basic operations, such as reading, writing, and listing files, and makes it easier to add new file systems.

Types of File Systems

The Solaris operating environment supports three types of file systems:

To identify the file system type, see Determining a File System's Type.

Disk-Based File Systems

Disk-based file systems are stored on physical media such as hard disks, CD-ROMs, and diskettes. Disk-based file systems can be written in different formats. The available formats are the following:

Disk-Based File System  

Format Description 


UNIX file system (based on the BSD Fast File system that was provided in the 4.3 Tahoe release). UFS is the default disk-based file system for the Solaris operating environment.

Before you can create a UFS file system on a disk, you must format the disk and divide it into slices. For information on formatting disks and dividing disks into slices, see Chapter 31, Managing Disks (Overview).


High Sierra, Rock Ridge, and ISO 9660 file system. High Sierra is the first CD-ROM file system. ISO 9660 is the official standard version of the High Sierra File System. The HSFS file system is used on CD-ROMs, and is a read-only file system. Solaris HSFS supports Rock Ridge extensions to ISO 9660, which, when present on a CD-ROM, provide all UFS file system features and file types, except for writability and hard links.


PC file system, which allows read and write access to data and programs on DOS-formatted disks that are written for DOS-based personal computers.


The Universal Disk Format (UDF) file system, the industry-standard format for storing information on the optical media technology called DVD (Digital Versatile Disc or Digital Video Disc).  

Each type of disk-based file system is customarily associated with a particular media device, as follows:

These associations are not, however, restrictive. For example, CD-ROMs and diskettes can have UFS file systems created on them.

Network-Based File Systems

Network-based file systems can be accessed from the network. Typically, network-based file systems reside on one system, typically a server, and are accessed by other systems across the network.

With NFS, you can administer distributed resources (files or directories) by exporting them from a server and mounting them on individual clients. For more information, see The NFS Environment.

Virtual File Systems

Virtual file systems are memory-based file systems that provide access to special kernel information and facilities. Most virtual file systems do not use file system disk space. However, the CacheFS file system uses a file system on the disk to contain the cache. Also, some virtual file systems, such as the temporary file system (TMPFS), use the swap space on a disk.

The CacheFS File System

The CacheFSTM file system can be used to improve performance of remote file systems or slow devices such as CD-ROM drives. When a file system is cached, the data that is read from the remote file system or CD-ROM is stored in a cache on the local system.

If you want to improve the performance and scalability of an NFS or CD-ROM file system, you should use the CacheFS file system. The CacheFS software is a general purpose caching mechanism for file systems that improves NFS server performance and scalability by reducing server and network load.

Designed as a layered file system, the CacheFS software provides the ability to cache one file system on another. In an NFS environment, CacheFS software increases the client per server ratio, reduces server and network loads, and improves performance for clients on slow links, such as Point-to-Point Protocol (PPP). You can also combine a CacheFS file system with the AutoFS service to help boost performance and scalability.

For detailed information about the CacheFS file system, see Chapter 40, Using The CacheFS File System (Tasks).

The Universal Disk Format (UDF) File System

The UDF file system is the industry-standard format for storing information on the DVD (Digital Versatile Disc or Digital Video Disc) optical media.

The UDF file system is provided as dynamically loadable, 32–bit and 64–bit modules, with system administration utilities for creating, mounting, and checking the file system on both SPARC and IA platforms. The Solaris UDF file system works with supported ATAPI and SCSI DVD drives, CD-ROM devices, and disk and diskette drives. In addition, the Solaris UDF file system is fully compliant with the UDF 1.50 specification.

The UDF file system provides the following features:

The following features are not included in the UDF file system:

The UDF file system requires the following:

The Solaris UDF file system implementation provides:

Temporary File System

The temporary file system (TMPFS) uses local memory for file system reads and writes, which is typically much faster than a UFS file system. Using TMPFS can improve system performance by saving the cost of reading and writing temporary files to a local disk or across the network. For example, temporary files are created when you compile a program, and the operating system generates a lot of disk activity or network activity while manipulating these files. Using TMPFS to hold these temporary files can significantly speed up their creation, manipulation, and deletion.

Files in TMPFS file systems are not permanent. They are deleted when the file system is unmounted and when the system is shut down or rebooted.

TMPFS is the default file system type for the /tmp directory in the Solaris operating environment. You can copy or move files into or out of the /tmp directory, just as you would in a UFS file system.

The TMPFS file system uses swap space as a temporary backing store. If a system with a TMPFS file system does not have adequate swap space, two problems can occur:

For information about creating TMPFS file systems, see Chapter 38, Creating File Systems (Tasks). For information about increasing swap space, see Chapter 41, Configuring Additional Swap Space (Tasks).

The Loopback File System

The loopback file system (LOFS) lets you create a new virtual file system so that you can access files by using an alternative path name. For example, you can create a loopback mount of root (/) on /tmp/newroot, which will make the entire file system hierarchy look like it is duplicated under /tmp/newroot, including any file systems mounted from NFS servers. All files will be accessible either with a path name starting from root (/), or with a path name that starts from /tmp/newroot.

For information on how to create LOFS file systems, see Chapter 38, Creating File Systems (Tasks).

Process File System

The process file system (PROCFS) resides in memory and contains a list of active processes, by process number, in the /proc directory. Information in the /proc directory is used by commands like ps. Debuggers and other development tools can also access the address space of the processes by using file system calls.

Caution – Caution –

Do not delete the files in the /proc directory. The deletion of processes from the /proc directory does not kill them. Remember, /proc files do not use disk space, so there is little reason to delete files from this directory.

The /proc directory does not require administration.

Additional Virtual File Systems

These additional types of virtual file systems are listed for your information. They do not require administration.

Virtual File System 


FIFOFS (first-in first-out) 

Named pipe files that give processes common access to data

FDFS (file descriptors) 

Provides explicit names for opening files using file descriptors


Provides read-only access to the table of mounted file systems for the local system 


Used mostly by STREAMS for dynamic mounts of file descriptors on top of files

SPECFS (special) 

Provides access to character special devices and block devices


Used by the kernel for swapping

Commands for File System Administration

Most commands for file system administration have both a generic component and a file system–specific component. Whenever possible, you should use the generic commands, which call the file system–specific component. The following table lists the generic commands for file system administration, which are located in the /usr/sbin directory.

Table 37–1 Generic Commands for File System Administration


Man Page 




Clears inodes 



Reports the number of free disk blocks and files 



Lists file names and statistics for a file system 



Checks the integrity of a file system and repairs any damage found 



Debugs the file system 



Determines the file system type 



Lists or provides labels for file systems when they are copied to tape (for use by the volcopy command only)



Creates a new file system 



Mounts local and remote file systems 



Mounts all file systems that are specified in the virtual file system table (/etc/vfstab)



Generates a list of path names with their inode numbers 



Unmounts local and remote file systems 



Unmounts all file systems that are specified in a virtual file system table (/etc/vfstab)



Creates an image copy of a file system 

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 37–2 The Default Solaris File Systems

File System or Directory 

File System Type 


root (/)


The top of the hierarchical file tree. The root directory contains the directories and files that are critical for system operation, such as the kernel, the device drivers, and the programs used to boot the system. The root directory also contains the mount point directories where local and remote file systems can be attached to the file tree. 



System files and directories that can be shared with other users. Files that run only on certain types of systems are in the /usr file system (for example, SPARC executables). Files that can be used on all types of systems, such as the man pages, are in the /usr/share directory.

/export/home or /home


The mount point for users' home directories, which store user work files. By default the /home directory is an automounted file system. On standalone systems, the /home directory might be a UFS file system on a local disk slice.



System files and directories that are likely to change or grow over the life of the local system. These include system logs, vi and ex backup files, and uucp files.



Optional mount point for third-party software. On some systems, the /opt directory might be a UFS file system on a local disk slice.



Temporary files, which are cleared each time the system is booted or the /tmp file system is unmounted.



A list of active processes, by number. 



A file system that provides read-only access to the table of mounted file systems for the local system. 



A file system for storing temporary files that are not needed after the system is booted. 

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 43, UFS File System (Reference).

Swap Space

The Solaris operating environment 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 41, Configuring Additional Swap Space (Tasks).

The UFS File System

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

UFS Feature 


State flags 

Show the state of the file system: clean, stable, active, logging, or unknown. These flags eliminate unnecessary file system checks. If the file system is “clean,” “stable,” or “logging,” file system checks are not run.

Extended fundamental types (EFT) 

Provides 32-bit user ID (UID), group ID (GID), and device numbers.

Large file systems 

Allows 1 Tbyte (terabyte) files in a UFS file system. The Solaris operating environment does not provide striping, which is required to make a logical slice large enough for a 1-Tbyte file system. However, Solaris Volume Manager provides this capability.

Large files 

Allows 2 Gbytes (gigabytes) files in a UFS file system by default. You must explicitly use the nolargefiles mount option to enforce a 2–Gbyte maximum file size limit.

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

UFS Logging

UFS logging is the process of storing transactions (changes that make up a complete UFS operation) in a log before the transactions are applied to the UFS file system. Once a transaction is stored, the transaction can later be applied to the file system later.

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:

The log created by UFS logging is continually flushed as it fills up. The log is flushed when the file system is unmounted or as a result of the lockfs -f command.

UFS logging is not enabled by default. To enable UFS logging, you must specify the -o logging option with the mount command in the /etc/vfstab file or when you mount the file system manually. 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. Logging can be enabled on any UFS file system, including the root (/) file system. Also, the fsdb command now has new debugging commands to support UFS logging.

Planning UFS File Systems

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

For information on default file system parameters as well as procedures for creating new UFS file systems, see Chapter 38, 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 37–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:

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

Figure 37–2 Mounting a File System


The Mounted File System Table

Whenever you mount or unmount a file system, the /etc/mnttab (mount table) file is modified with the list of currently mounted file systems. You can display the contents of this file with the cat or more commands, but you cannot edit it. Here is an example of an /etc/mnttab file:

$ more /etc/mnttab
/dev/dsk/c0t0d0s0  /  ufs rw,intr,largefiles,onerror=panic,suid,dev=2200000 938557523
/proc   /proc   proc    dev=3180000     938557522
fd      /dev/fd fd      rw,suid,dev=3240000     938557524
mnttab  /etc/mnttab     mntfs   dev=3340000     938557526
swap    /var/run        tmpfs   dev=1   938557526
swap    /tmp    tmpfs   dev=2   938557529
/dev/dsk/c0t0d0s7 /export/home ufs rw,intr,largefiles,onerror=panic,suid,dev=2200007 ...

The Virtual File System Table

It would be a very time-consuming and error-prone task to manually mount file systems every time you wanted to access them. To avoid this problem, the virtual file system table (the /etc/vstab file) provides a list of file systems and how to mount them.

The /etc/vfstab file provides two important features:

A default /etc/vfstab file is created when you install a system, depending on the selections you make when installing system software. However, you can edit the /etc/vfstab file on a system whenever you want. To add an entry, the main information you need to specify is the device where the file system resides, the name of the mount point, the type of the file system, whether you want the file system to mount automatically when the system boots (by using the mountall command), and any mount options.

The following is an example of an /etc/vfstab file. Comment lines begin with #. This example shows an /etc/vfstab file for a system with two disks (c0t0d0 and c0t3d0).

$ more /etc/vfstab
#device         device          mount           FS      fsck   mount  mount
#to mount       to fsck         point           type    pass   at boot options
/dev/dsk/c0t0d0s0 /dev/rdsk/c0t0d0s0 /          ufs     1       no      -
/proc           -               /proc           proc    -       no      -
/dev/dsk/c0t0d0s1 -                -            swap    -       no      -
swap            -               /tmp            tmpfs   -       yes     -
/dev/dsk/c0t0d0s6 /dev/rdsk/c0t0d0s6 /usr       ufs     2       no      -
/dev/dsk/c0t3d0s7 /dev/rdsk/c0t3d0s7 /test      ufs     2       yes     -

In the preceding example, the last entry specifies that a UFS file system on the /dev/dsk/c0t3d0s7 slice will be automatically mounted on the /test mount point when the system boots. Note that, for root (/) and /usr, the mount at boot field value is specified as no, because these file systems are mounted by the kernel as part of the boot sequence before the mountall command is run.

For descriptions of each of the /etc/vfstab fields and information on how to edit and use the file, see Chapter 39, Mounting and Unmounting File Systems (Tasks).

The NFS Environment

NFS is a distributed file system service that can be used to share resources (files or directories) from one system, typically a server, with other systems on the network. For example, you might want to share third-party applications or source files with users on other systems.

NFS makes the actual physical location of the resource irrelevant to the user. Instead of placing copies of commonly used files on every system, NFS allows you to place one copy on one system's disk and let all other systems access it from the network. Under NFS, remote files are virtually indistinguishable from local ones.

A system becomes an NFS server if it has resources to share on the network. A server keeps a list of currently shared resources and their access restrictions (such as read/write or read-only access).

When you share a resource, you make it available for mounting by remote systems.

You can share a resource in these ways:

For information on how to share resources, see Chapter 39, Mounting and Unmounting File Systems (Tasks). For a complete description of NFS, see “Managing Network File Systems (Overview)” in System Administration Guide: Resource Management and Network Services.

Automounting or AutoFS

You can mount NFS file system resources by using a client-side service called automounting (or AutoFS), which enables a system to automatically mount and unmount NFS resources whenever you access them. The resource remains mounted as long as you remain in the directory and are using a file. If the resource is not accessed for a certain period of time, it is automatically unmounted.

AutoFS provides the following features:

The AutoFS service is initialized by the automount utility, which runs automatically when a system is booted. The automountd daemon runs continuously and is responsible for the mounting and unmounting of the NFS file systems on an as-needed basis. By default, the /home file system is is mounted by the automount daemon.

With AutoFS, you can specify multiple servers to provide the same file system. This way, if one of the servers is down, AutoFS can try to mount from another machine.

For complete information on how to set up and administer AutoFS, see System Administration Guide: IP Services.

Determining a File System's Type

You can determine a file system's type by using the following:

How to Determine a File System's Type

This procedure works whether the file system is mounted or not.

Determine a file system's type by using the grep command.

$ grep mount-point fs-table


Specifies the mount point name of the file system for which you want to know the file system type. For example, the /var directory.


Specifies the absolute path to the file system table in which to search for the file system's type. If the file system is mounted, fs-table should be /etc/mnttab. If the file system isn't mounted, fs-table should be /etc/vfstab.

Information for the mount point is displayed.

Note –

If you have the raw device name of a disk slice, you can use the fstyp command to determine a file system's type (if the disk slice contains a file system). For more information, see fstyp(1M).

Example—Determining a File System's Type

The following example uses the /etc/vfstab file to determine the type of the /export file system.

$ grep /export /etc/vfstab
/dev/dsk/c0t3d0s6   /dev/rdsk/c0t3d0s6  /export ufs   2       yes    -

The following example uses the /etc/mnttab file to determine the file system type of the currently mounted diskette (which was mounted by vold).

$ grep /floppy /etc/mnttab
/vol/dev/diskette0/unnamed_floppy   /floppy/unnamed_floppy  pcfs rw,
nohidden,nofoldcase,dev=16c0009      89103376