Chapter 15 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 in the Solaris 9 Update Releases?

• Where to Find File System Management Tasks

• Overview of File Systems

• Types of File Systems

• Commands for File System Administration

• The Default Solaris File Systems

• Swap Space

• The UFS File System

• Mounting and Unmounting File Systems

• Determining a File System's Type

What's New in File Systems in the Solaris 9 Update Releases?

This section describes a new file system feature in this Solaris release.

UFS Logging Is Enabled by Default

Solaris 9 9/04 – Logging is enabled by default for all UFS file systems except under the following conditions:

• When logging is explicitly disabled.

• If there is insufficient file system space for the log.

In previous Solaris releases, you had to manually enable UFS logging. For more information about UFS logging, see UFS Logging.

Keep the following issues in mind when using UFS logging in this release:

• Ensure that you have enough disk space for your general system needs, such as for users and applications, and for UFS logging.

• If you don't have enough disk space for logging data, a message similar to the following is displayed:

  # mount /dev/dsk/c0t4d0s0 /mnt /mnt: No space left on device Could not enable logging for /mnt on /dev/dsk/c0t4d0s0. #

  However, the file system is still mounted. For example:

  # df -h /mnt Filesystem size used avail capacity Mounted on /dev/dsk/c0t4d0s0 142M 142M 0K 100% /mnt #

• A UFS file system with logging enabled that is generally empty will have some disk space consumed for the log.

• If you upgrade to this Solaris release from a previous Solaris release, your UFS file systems will have logging enabled, even if the logging option was not specified in the /etc/vfstab file. To disable logging, add the nologging option to the UFS file system entries in the /etc/vfstab file.

Default Logging and Standards Conformance

UFS file system transactions that free blocks from files might not immediately add the freed blocks to the file system's free list. This behavior occurs on a system that has a UFS file system mounted with logging enabled.

This behavior improves file system performance, but does not conform to the following standards:

• POSIX, Single UNIX® Specification

• SPARC® Conformance Definition

• SPARC Conformance Definition System V Application Binary Interface

• System V Interface Definition

• X/Open® Portability Guide

These standards require that freed space be available immediately.

Consider disabling UFS logging under the following conditions:

• You want to enable standards conformance regarding file deletions.

• You encounter problems creating or growing files immediately after the files have been deleted on a relatively full file system.

For more information, see mount_ufs(1M).

SPARC: Support of Multiterabyte UFS File Systems

Solaris 9 8/03 – This Solaris release provides support for multiterabyte UFS file systems on systems that run a 64-bit Solaris kernel.

Previously, UFS file systems were limited to approximately 1 terabyte on both 64-bit and 32-bit systems. All UFS file system commands and utilities have been updated to support multiterabyte UFS file systems.

For example, the ufsdump command has been updated with a larger block size for dumping large UFS file systems:

# ufsdump 0f /dev/md/rdsk/d97 /dev/md/rdsk/d98
  DUMP: Date of this level 0 dump: Tue Jan 07 14:23:36 2003
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/md/rdsk/d98 to /dev/md/rdsk/d97.
  DUMP: Mapping (Pass I) [regular files]
  DUMP: Mapping (Pass II) [directories]
  DUMP: Forcing larger tape block size (2048).
  DUMP: Writing 32 Kilobyte records
  DUMP: Estimated 4390629500 blocks (2143862.06MB).
  DUMP: Dumping (Pass III) [directories]
  DUMP: Dumping (Pass IV) [regular files]

Administering UFS file systems that are less than 1 terabyte remains the same. No administration differences exist between UFS file systems that are less than one terabyte and file systems that are greater than 1 terabyte.

You can initially create a UFS file system that is less than 1 terabyte and specify that it can eventually be expanded into a multiterabyte file system by using the newfs -T option. This option sets the inode and fragment density to scale appropriately for a multiterabyte file system.

Using the newfs -T option when you create a UFS file system less than 1 terabyte on a system running a 32-bit kernel enables you to eventually expand this file system with the growfs command when you boot this system under a 64-bit kernel. For more information, see newfs(1M).

You can use the growfs command to expand a UFS file system to the size of the slice or the volume without loss of service or data. For more information, see growfs(1M).

Two new related features are multiterabyte volume support with the EFI disk label and multiterabyte volume support with Solaris Volume Manager. For more information, see SPARC: Multiterabyte Disk Support With EFI Disk Label and the Solaris Volume Manager Administration Guide

Features of Multiterabyte UFS File Systems

Multiterabyte UFS file systems include the following features:

• The ability to create a UFS file system up to 16 terabytes in size.

• The ability to create a file system less than 16 terabytes that can later be increased in size up to 16 terabytes.

• Multiterabyte file systems can be created on physical disks, Solaris Volume Manager's logical volumes, and Veritas' VxVM logical volumes.

• Multiterabyte file systems benefit from the performance improvements of having UFS logging enabled. Multiterabyte file systems also benefit from the availability of logging because the fsck command might not have to be run when logging is enabled.

• When you create a partition for your multiterabyte UFS file system, the disk will be labeled automatically with an EFI disk label. For more information on EFI disk labels, see SPARC: Multiterabyte Disk Support With EFI Disk Label.

Limitations of Multiterabyte UFS File Systems

Limitations of multiterabyte UFS file systems are as follows:

• This feature is not supported on Solaris x86 systems.

• You cannot mount a file system greater than 1 terabyte on a system that is running a 32-bit Solaris kernel.

• You cannot boot from a file system greater than 1 terabyte on a system that is running a 64-bit Solaris kernel. This limitation means that you cannot put a root (/) file system on a multiterabyte file system.

• There is no support for individual files greater than 1 terabyte.

• The maximum number of files is 1 million files per terabyte of UFS file system. For example, a 4–terabyte file system can contain 4 million files.

  This limit is intended to reduce the time it takes to check the file system with the fsck command.

• The maximum quota that you can set on a multiterabyte UFS file system is 2 terabytes of 1024-byte blocks.

• Using the fssnap command to create a snapshot of a multiterabyte UFS file system is not currently supported.

How to Create a Multiterabyte UFS File System

Support for a multiterabyte UFS file system assumes the availability of multiterabyte LUNs, provided as Solaris Volume Manager or VxVM volumes, or as physical disks greater than 1 terabyte.

Before you can create a multiterabyte UFS file system, verify that you have done either of the following:

• Created a multiterabyte disk partition with the format utility or the Solaris installation utilities.

• Set up a multiterabyte volume with Solaris Volume Manager.

Steps

1. Become superuser.

2. Create a multiterabyte UFS file system on a logical volume.

   For example, this command creates a UFS file system for a 1.8 terabyte volume.

   # newfs /dev/md/rdsk/d99 newfs: construct a new file system /dev/md/rdsk/d99: (y/n)? y /dev/md/rdsk/d99: 3859402752 sectors in 628158 cylinders of 48 tracks, 128 sectors 1884474.0MB in 4393 cyl groups (143 c/g, 429.00MB/g, 448 i/g) super-block backups (for fsck -F ufs -o b=#) at: 32, 878752, 1757472, 2636192, 3514912, 4393632, 5272352, 6151072, 702... Initializing cylinder groups: ........................................................................ super-block backups for last 10 cylinder groups at: 3850872736, 3851751456, 3852630176, 3853508896, 3854387616, 3855266336, 3856145056, 3857023776, 3857902496, 3858781216, #

3. Verify the integrity of the newly created file system.

   For example:

   # fsck /dev/md/rdsk/d99 ** /dev/md/rdsk/d99 ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 2 files, 2 used, 241173122 free (0 frags, 241173122 blocks, 0.0% fragmentation) #

4. Mount and verify the newly created file system.

   For example:

   # mount /dev/md/dsk/d99 /bigdir # df -h /bigdir Filesystem size used avail capacity Mounted on /dev/md/dsk/d99 1.8T 64M 1.8T 1% /bigdir

How to Expand a Multiterabyte UFS File System

After a multiterabyte UFS file system is created, you can use the growfs command to expand the file system. For example, using the file system that was created for the volume in the preceding procedure, you can add another disk to this volume. Then, expand the file system.

Steps

1. Become superuser.

2. Add another disk to the volume.

   For example:

   # metattach d99 c4t5d0s4 d99: component is attached # metastat d99: Concat/Stripe Size: 5145882624 blocks (2.4 TB) Stripe 0: Device Start Block Dbase Reloc c0t1d0s4 36864 Yes Yes Stripe 1: Device Start Block Dbase Reloc c3t7d0s4 0 No Yes Stripe 2: Device Start Block Dbase Reloc c1t1d0s4 0 No Yes Stripe 3: Device Start Block Dbase Reloc c4t5d0s4 0 No Yes

3. Expand the file system.

   For example:

   # growfs -v /dev/md/rdsk/d99 /usr/lib/fs/ufs/mkfs -G /dev/md/rdsk/d99 5145882624 /dev/md/rdsk/d99: 5145882624 sectors in 837546 cylinders of 48 tracks, 128 sectors 2512638.0MB in 5857 cyl groups (143 c/g, 429.00MB/g, 448 i/g) super-block backups (for fsck -F ufs -o b=#) at: 32, 878752, 1757472, 2636192, 3514912, 4393632, 5272352, 6151072, 702... Initializing cylinder groups: ......................................................................... super-block backups for last 10 cylinder groups at: 5137130400, 5138009120, 5138887840, 5139766560, 5140645280, 5141524000, 5142402720, 5143281440, 5144160160, 5145038880, #

4. Mount and verify the expanded file system.

   For example:

   # mount /dev/md/dsk/d99 /bigdir # df -h /bigdir Filesystem size used avail capacity Mounted on /dev/md/dsk/d99 2.4T 64M 2.4T 1% /bigdir

How to Expand a UFS File System to a Multiterabyte UFS File System

Use the following procedure to expand a UFS file system to greater than 1 terabyte in size. This procedure assumes that the newfs -T option was used initially to create the UFS file system.

Steps

1. Become superuser.

2. Identify the size of the current disk or volume.

   For example, the following volume is 800 gigabytes.

   # metastat d98 d98: Concat/Stripe Size: 1677754368 blocks (800 GB) Stripe 0: Device Start Block Dbase Reloc c0t1d0s4 0 No Yes Stripe 1: Device Start Block Dbase Reloc c3t7d0s4 0 No Yes

3. Increase the volume to greater than 1 terabyte.

   For example:

   # metattach d98 c1t1d0s4 d98: component is attached # metastat d98 d98: Concat/Stripe Size: 2516631552 blocks (1.2 TB) Stripe 0: Device Start Block Dbase Reloc c0t1d0s4 0 No Yes Stripe 1: Device Start Block Dbase Reloc c3t7d0s4 0 No Yes Stripe 2: Device Start Block Dbase Reloc c1t1d0s4 0 No Yes

4. Expand the UFS file system for the disk or volume to greater than 1 terabyte.

   For example:

   growfs -v /dev/md/rdsk/d98 /usr/lib/fs/ufs/mkfs -G /dev/md/rdsk/d98 2516631552 /dev/md/rdsk/d98: 2516631552 sectors in 68268 cylinders of 144 tracks, 256 sectors 1228824.0MB in 2731 cyl groups (25 c/g, 450.00MB/g, 448 i/g) super-block backups (for fsck -F ufs -o b=#) at: 32, 921888, 1843744, 2765600, 3687456, 4609312, 5531168, 6453024, 737... 8296736, Initializing cylinder groups: ...................................................... super-block backups for last 10 cylinder groups at: 2507714848, 2508636704, 2509558560, 2510480416, 2511402272, 2512324128, 2513245984, 2514167840, 2515089696, 2516011552,

5. Mount and verify the expanded file system.

   For example:

   # mount /dev/md/dsk/d98 /datadir # df -h /datadir Filesystem size used avail capacity Mounted on /dev/md/dsk/d98 1.2T 64M 1.2T 1% /datadir

Troubleshooting Multiterabyte UFS File System Problems

Use the following error messages and solutions to troubleshoot problems with multiterabyte UFS file systems.

Error Message (similar to the following):

mount: /dev/rdsk/c0t0d0s0 is not this fstype.

Cause

You attempted to mount a UFS file system that is greater than 1 terabyte on a system running a Solaris release prior to the Solaris 9 8/03 release.

Solution

Mount a UFS file system that is greater than 1 terabyte on a system running the Solaris 9 8/03 or later release.

Error Message

"File system was not set up with the multi-terabyte format." "Its size cannot be increased to a terabyte or more."

Cause

You attempted to expand a file system that was not created with the newfs -T command.

Solution

1. Back up the data for the file system that you want to expand to greater than one terabyte.

2. Re-create the file system with the newfs command to create a multiterabyte file system.

3. Restore the backup data into the newly created file system.

Where to Find File System Management Tasks

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

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:

• A particular type of file system: disk-based, network-based, or virtual

• The entire file tree, beginning with the root directory

• The data structure of a disk slice or other media storage device

• A portion of a file tree structure that is attached to a mount point on the main file tree so that the files are accessible

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

The Solaris operating system 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 system supports three types of file systems:

• Disk-based

• Network-based

• Virtual

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:

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

• UFS with hard disk

• HSFS with CD-ROM

• PCFS with diskette

• UDF with DVD

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 CacheFS^TM 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 18, 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 x86 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:

• Ability to access the industry standard CD-ROM and DVD-ROM media when they contain a UDF file system

• Flexibility in exchanging information across platforms and operating systems

• A mechanism for implementing new applications rich in broadcast-quality video, high-quality sound along with the richness in interactivity using the DVD video specification based on UDF format

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

• Support for write-once media, CD-RW, and DVD-RAM, with either the sequential disk-at-once and incremental recording

• UFS components such as quotas, ACLs, transaction logging, file system locking, and file system threads, which are not part of the UDF 1.50 specification

The UDF file system requires the following:

• At least the Solaris 7 11/99 release

• Supported SPARC or x86 platforms

• Supported CD-ROM or DVD-ROM device

The Solaris UDF file system implementation provides:

• Support for industry-standard read/write UDF version 1.50

• Fully internationalized file system utilities

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 system. 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:

• The TMPFS file system can run out of space, just as regular file systems do.

• Because TMPFS allocates swap space to save file data (if necessary), some programs might not execute because of insufficient swap space.

For information about creating TMPFS file systems, see Chapter 16, Creating UFS, TMPFS, and LOFS File Systems (Tasks). For information about increasing swap space, see Chapter 19, 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 16, Creating UFS, TMPFS, and LOFS 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.

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.

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.

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.

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 section 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.

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

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 16, Creating UFS, TMPFS, and LOFS File Systems (Tasks).

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.

• Starting in the Solaris 9 12/02 release, the performance of UFS logging improves or exceeds the level of performance of non-logging file systems. This improvement can occur 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 for all UFS file systems.

If you need to disable UFS logging, add the nologging option to the file system's entry in the /etc/vfstab file or when you mount the file system manually.

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, including the root (/) 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.

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 24, Using UFS Snapshots (Tasks) for more information.

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 15–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 17, Mounting and Unmounting File Systems (Tasks).

Figure 15–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/vfstab file) provides a list of file systems and how to mount them.

The /etc/vfstab file provides two important features:

• You can specify file systems to automatically mount when the system boots.

• You can mount file systems by using only the mount point name, because the /etc/vfstab file contains the mapping between the mount point and the actual device slice name.

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 17, 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:

• By using the share or shareall command

• By adding an entry to the /etc/dfs/dfstab (distributed file system table) file and rebooting the system

For information on how to share resources, see Chapter 17, Mounting and Unmounting File Systems (Tasks). For a complete description of NFS, see Chapter 14, 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:

• NFS resources don't need to be mounted when the system boots, which saves booting time.

• Users don't need to know the root password to mount and unmount NFS resources.

• Network traffic might be reduced, since NFS resources are only mounted when they are in use.

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:

• The FS type field in the virtual file system table (/etc/vfstab file)

• The /etc/default/fs file for local file systems

• The /etc/dfs/fstypes file for NFS file systems

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

mount-point

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

fs-table

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.

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).

Examples—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
$