File System Operations

This section describes the Solaris utilities used for creating, checking, repairing, and mounting file systems. Use these utilities to make file systems available to the user and to ensure their reliability.

Synchronizing a File System

The UFS file system relies on an internal set of tables to keep track of inodes as well as used and available blocks. When a user performs an operation that requires data to be written to the disk, the data to be written is first copied into a buffer in the kernel. Normally, the disk update is not handled until long after the write operation has returned. At any given time, the file system, as it resides on the disk, might lag behind the state of the file system represented by the buffers located in physical memory (RAM). The internal tables finally get updated when the buffer is required for another use or when the kernel automatically runs the fsflush daemon (at 30-second intervals).

If the system is halted without writing out the memory-resident information, the file system on the disk will be in an inconsistent state. If the internal tables are not properly synchronized with data on the disk, inconsistencies result, data may be lost, and file systems will need repairing. File systems can be damaged or become inconsistent because of abrupt termination of the operating system in these ways:

• Experiencing power failure

• Accidentally unplugging the system

• Turning off the system without the proper shutdown procedure

• Performing a Stop+A (L1+A)

• Encountering a software error in the kernel

• Encountering a hardware failure that halts the system unexpectedly

To prevent unclean halts, the current state of the file system must be written to disk (that is, synchronized) before you halt the CPU or take a disk offline.

Repairing File Systems

During normal operation, files are created, modified, and removed. Each time a file is modified, the operating system performs a series of file system updates. When a system is booted, a file system consistency check is automatically performed. Most of the time, this file system check repairs any problems it encounters. File systems are checked with the fsck (file system check) command.

The Solaris fsck command uses a state flag, which is stored in the superblock, to record the condition of the file system. Following are the possible state values:

• FSCLEANIf the file system was unmounted properly, the state flag is set to FSCLEAN. Any file system with an FSCLEAN state flag is not checked when the system is booted.

• FSSTABLEOn a mounted file system, this state indicates that the file system has not changed since the last sync or fsflush. File systems marked as FSSTABLE can skip fsck before mounting.

• FSACTIVEThe state flag gets set to FSACTIVE when a file system is mounted and modified. The FSACTIVE flag goes into effect before any modifications are written to disk, however. The exception is when a file system is mounted with UFS logging and the flag is set to FSLOG, as described later. When a file system is unmounted properly, the state flag is then set to FSCLEAN. A file system with the FSACTIVE flag must be checked by fsck because it might be inconsistent. The system does not mount a file system for read/write unless its state is FSCLEAN, FSLOG, or FSSTABLE.

• FSBADIf the root file system is mounted when its state is not FSCLEAN or FSSTABLE, the state flag is set to FSBAD. A root file system flagged as FSBAD as part of the boot process is mounted as read-only. You can run fsck on the raw root device and then remount the root file system as read/write.

• FSLOGIf the file system was mounted with UFS logging, the state flag is set to FSLOG. Any file system with an FSLOG state flag is not checked when the system is booted. See the section titled "Mounting a File System with UFS Logging Enabled," where I describe mounting a file system from the command line later in this chapter.

fsck is a multipass file system check program that performs successive passes over each file system, checking blocks and sizes, pathnames, connectivity, reference counts, and the map of free blocks (possibly rebuilding it). fsck also performs cleanup. The phases (passes) performed by the UFS version of fsck are described in Table 1.11.

Table 1.11. fsck Phases

fsck Phase	Task Performed
Phase 1	Checks blocks and sizes
Phase 2	Checks pathnames
Phase 3	Checks connectivity
Phase 4	Checks reference counts
Phase 5	Checks cylinder groups

Normally, fsck is run noninteractively at bootup to preen the file systems after an abrupt system halt in which the latest file system changes were not written to disk. Preening automatically fixes any basic file system inconsistencies but does not try to repair more serious errors. While preening a file system, fsck fixes the inconsistencies it expects from such an abrupt halt. For more serious conditions, the command reports the error and terminates. It then tells the operator to run fsck manually.

Determining Whether a File System Needs Checking

File systems must be checked periodically for inconsistencies to avoid unexpected loss of data. As stated earlier, checking the state of a file system is automatically done at bootup; however, it is not necessary to reboot a system to check whether the file systems are stable as described in Step by Step 1.10.

Step By Step 1.10: Determining the Current State of the File System 1. Become a superuser. 2. Type fsck -m /dev/rdsk/cntndnsn and press Enter. The state flag in the superblock of the file system you specify is checked to see whether the file system is clean or requires checking. If you omit the device argument, all the UFS file systems listed in /etc/vfstab with an fsck pass value of greater than 0 are checked.

In the following example, the first file system needs checking, but the second file system does not:

fsck -m /dev/rdsk/c0t0d0s6

** /dev/rdsk/c0t0d0s6
ufs fsck: sanity check: /dev/rdsk/c0t0d0s6 needs checking
fsck -m /dev/rdsk/c0t0d0s7
** /dev/rdsk/c0t0d0s7
ufs fsck: sanity check: /dev/rdsk/c0t0d0s7 okay

Running fsck Manually

You might need to manually check file systems when they cannot be mounted or when you've determined that the state of a file system is unclean. Good indications that a file system might need to be checked are error messages displayed in the console window or system crashes that occur for no apparent reason.

When you run fsck manually, it reports each inconsistency found and fixes innocuous errors. For more serious errors, the command reports the inconsistency and prompts you to choose a response. Sometimes corrective actions performed by fsck result in some loss of data. The amount and severity of data loss can be determined from the fsck diagnostic output. The procedure outlined in Step by Step 1.11 describes how to check a file system by running the fsck command manually.

Step By Step 1.11: Manually Checking File Systems 1. Log in as root and unmount the file system. 2. After the file system is unmounted, type fsck /dev/rdsk/<device> and press Enter. If you do not specify a device, all file systems in the /etc/vfstab file with entries greater than 0 in the fsck pass field are checked, including root (/). As stated earlier, you must be in single-user mode to run fsck on root. You can also specify the mount point directory as an argument to fsck, and as long as the mount point has an entry in the /etc/vfstab file, fsck will be able to resolve the path to the raw device. The fsck command requires the raw device filename. 3. Any inconsistency messages are displayed. The only way to successfully change the file system and correct the problem is to answer yes to these messages. Note Supply an Automatic Yes Response to fsck The fsck command has a -y option that automatically answers yes to every question. But be careful: If fsck asks to delete a file, it will answer yes and you will have no control over it. If it doesn't delete the file, however, the file system remains unclean and cannot be mounted. 4. If you corrected any errors, type fsck /dev/rdsk/<device> and press Enter. fsck might not be capable of fixing all errors in one execution. If you see the message FILE SYSTEM STATE NOT SET TO OKAY, run the command again and continue to run fsck until it runs clean with no errors. 5. Rename and move any files put in lost+found. Individual files put in the lost+found directory by fsck are renamed with their inode numbers, so figuring out what they were named originally can be difficult. If possible, rename the files and move them where they belong. You might be able to use the grep command to match phrases with individual files and use the file command to identify file types, ownership, and so on. When entire directories are dumped into lost+found, it is easier to figure out where they belong and move them back.

newfs -Nv <raw device name>

The labelit Command

After you create the file system with newfs, you can use the labelit utility to write or display labels on unmounted disk file systems. The syntax for labelit is as follows:

labelit <-F <fstype>> <-V> <special> <fsname volume>

Labeling a file system is optional. It's required only if you're using a program such as volcopy, which will be covered soon. The labelit command is described in Table 1.12.

Table 1.12. The labelit Command

Parameter	Description
<special>	This name should be the physical disk slice (for example, /dev/dsk/c0t0d0s6).
<fsname>	This represents the mount point (for example, root [/], /home, and so on) of the file system.
<volume>	This can be used to represent the physical volume name.
-F <fstype>	This specifies the file system type on which to operate. The file system type should either be specified here or be determinable from the /etc/vfstab enTRy. If no matching entry is found, the default file system type specified in /etc/default/fs is used.
-V	This prints the command line but does not perform an action.

The following is an example of how to label a disk partition using the labelit command. Type the following:

labelit -F ufs /dev/rdsk/c0t0d0s6 disk1 vol1

The system responds with this:

fsname: disk1
volume: vol1

The volcopy Command

The administrator (root) can use the volcopy command to make a copy of a labeled file system. This command works with UFS file systems, but the file system must be labeled with the labelit utility before the volcopy command is issued. To determine whether a file system is a UFS, issue this command:

fstyp  /dev/rdsk/c0t0d0s6

The system responds with this:

ufs

The volcopy command can be used to copy a file system from one disk to another.

The syntax for volcopy is as follows:

volcopy <options> <fsname> <srcdevice> <volname1> <destdevice> <volname2>

volcopy is described in Table 1.13.

Table 1.13. The volcopy Command

Option	Description
-F <fstype>	This specifies the file system type on which to operate. This should either be specified here or be determinable from the /etc/vfstab enTRy. If no matching entry is found, the default file system type specified in /etc/default/fs is used.
-V	This prints the command line but does not perform an action.
-a	This requires the operator to respond yes or no. If the -a option is not specified, volcopy pauses 10 seconds before the copy is made.
-o <options>	This is a list of options specific to the type of file system. The list must have the following format: -o followed by a space, followed by a series of keyword [=value] pairs, separated by commas, with no intervening spaces.
<fsname>	This represents the mount point (for example, /, /u1, and so on) of the file system being copied.
<srcdevice> / <destdevice>	This is the disk partition specified using the raw device (for example, /dev/rdsk/clt0d0s7, /dev/rdsk/clt0d1s7, and so on).
<srcdevice> / <volname1>	This is the device and physical volume from which the copy of the file system is being extracted.
<destdevice> / <volname2>	This is the target device and physical volume.

The following example copies the contents of /home1 (/dev/rdsk/c0t0d0s6) to /home2 (/dev/rdsk/c0t1d0s6):

volcopy -F ufs home1 /dev/rdsk/c0t0d0s6 home2 /dev/rdsk/c0t1d0s6 vol2

Other commands can also be used to copy file systemsufsdump, cpio, tar, and dd, to name a few. These commands are discussed in Chapter 7, "Performing System Backups and Restorations."