Checking the Data Consistency of a File System (fsck)
The UFS file system relies on an internal set of tables to keep track of inodes—structures the kernel uses to maintain information about each file— and used and available blocks. When these internal tables are not properly synchronized with data on a disk, inconsistencies result and file systems need to be repaired.
File systems can be damaged or become inconsistent because of abrupt termination of the operating system in the following ways.
Power failure. The system halted by either the halt or uadmin command. The system turned off without proper shutdown procedure. A software error in the kernel.
File system corruption, though serious, is not common. When a system is booted, a file system consistency check is done automatically. Most of the time, this file system check repairs problems it encounters.
Check file systems with the fsck (file system check) command. The fsck command puts files and directories that are allocated but unreferenced in the lost+found directory in that file system. The inode number of each file is assigned to the name of the recovered file. If the lost+found directory does not exist, fsck creates it. If there is not enough space in the lost+found directory, fsck increases its size.
You may need to interactively check file systems in the following cases.
NOTE. When an in-use file system develops inconsistencies, strange error messages may be displayed in the console window or the system may crash. Before using fsck, you may want to refer to the fsck (1M) manual page for more information.
Finding Out Whether a File System Needs Checking
Use the following steps to determine whether a file system needs to be checked.
Become superuser.
Unmount the file system if it is mounted.
Typefsck -m /dev/rdsk/cntndnsnandpress Return.
The state flag in the superblock of the file system you specify is checked to determine whether the file system is clean or requires checking.
If you omit the device argument in the fsck command, all the UFS file systems listed in /etc/vfstab with a fsck pass value greater than 0 are checked. In the following example, the first file system needs to be checked; the second file system does not.
paperbark% su
Password:
# umount /dev/rdsk/c0t0d0s6
# fsck -m /dev/rdsk/c0t0d0s6
** /dev/rdsk/c0t0d0s6
ufs fsck: sanity check: /dev/rdsk/c0t0d0s6 needs checking
# umount /dev/rdsk/c0t0d0s7
# fsck -m /dev/rdsk/c0t0d0s7
** /dev/rdsk/c0t0d0s7
ufs fsck: sanity check: /dev/rdsk/c0t0d0s7 okay
#
Checking File Systems Interactively
Use the following steps to check all file systems interactively.
Become superuser.
Unmount the file system.
Type fsck and press Return.
All file systems in the /etc/vfstab file with entries in the fsck pass field greater than 0 are checked. You can also specify the mount point directory or /dev/rdsk/cntndnsn as arguments to fsck. Any inconsistency messages are displayed.
In the following example, /dev/rdsk/c0t0d0s6 is checked and the incorrect block count is corrected.
paperbark% su
Password:
# umount /dev/rdsk/c0t0d0s6
# fsck /dev/rdsk/c0t0d0s6
checkfilesys: /dev/rdsk/c0t0d0s6
** Phase 1 - Check Block and Sizes
INCORRECT BLOCK COUNT I=2529 (6 should be 2)
CORRECT? y
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Cylinder Groups
Dynamic 4.3 FFFS
929 files, 8928 used, 2851 free (75 frags, 347 blocks, 0.6% fragmentation)
/dev/rdsk/c0t0d0s6 FILE SYSTEM STATE SET TO OKAY
***** FILE SYSTEM WAS MODIFIED *****
|