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.
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. 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 and file systems 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.
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. This flag is used by the fsck command to determine whether a file system needs to be checked for consistency. The flag is used by the /etc/bcheckrc script during booting and by the fsck command when run from a command line using the -m option. Following are the possible state values:
FSCLEAN If 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.
FSSTABLE On 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.
FSACTIVE The 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 or FSSTABLE.
FSBAD If 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.
FSLOG If 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 14.3.
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.
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 if the file systems are stable.
Exercise 14.6 Determining the Current State of the File System
The following procedure outlines a method for determining the current state of the file systems and whether they need to be fixed:
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 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
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 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.
Exercise 14.7 Manually Checking File Systems
To check all file systems manually, you must first log in as root and unmount the file system . After the file system is unmounted, type fsck and press Enter.
Note
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>
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 ufs] [-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 14.4.
Note
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:
fsname: disk1 volume: vol1
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 file system, 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 14.5.
Note
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 systems—ufsdump, cpio, tar, and dd, to name a few. These commands are discussed in Chapter 20, “Backup and Recovery.”