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
Understand all aspects of repairing a file system. Know everything from unmounting a faulty file system, checking a file system, creating a new file system, and restoring data to that file system.
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.
Never run the fsck command on a mounted file system. This could leave the file system in an unstable state and could result in the loss of data. Because the / (root), /usr, and /var file systems cannot be unmounted, these file systems should only have fsck run on them while in single-user mode.
Reboot the system immediately after running the fsck on these mounted file systems.
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
Checks blocks and sizes
Checks reference counts
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.
Become a superuser.
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
ufs fsck: sanity check: /dev/rdsk/c0t0d0s6 needs checking
fsck -m /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.
Log in as root and unmount the file system.
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.
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.
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.
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.
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
Locating the Alternate Superblock Occasionally the file system's superblock can become corrupted and fsck will ask you for the location of an alternate superblock. This information can be obtained by typing
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
This name should be the physical disk slice (for example, /dev/dsk/c0t0d0s6).
This represents the mount point (for example, root [/], /home, and so on) of the file system.
This can be used to represent the physical volume name.
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.
This prints the command line but does not perform an action.
View Current Labels If fsname and volume are not specified, labelit prints the current values of these labels. Both fsname and volume are limited to six or fewer characters.
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:
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:
The system responds with this:
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
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.
This prints the command line but does not perform an action.
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.
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.
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.
fsname and volname Limits fsname and volname are limited to six or fewer characters and are recorded in the superblock. volname can be a dash (-) to use the existing volume name.
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."