How to See If a File System Needs Checking
Become superuser or assume an equivalent role.
Unmount the file system if it is mounted.
# umount /mount-point
Check the file system.
# fsck -m /dev/rdsk/device-name
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 the /etc/vfstab file with a fsck pass value greater than 0 are checked.
Example--Seeing If a File System Needs Checking
The following example shows that the file system needs checking.
# fsck -m /dev/rdsk/c0t0d0s6 ** /dev/rdsk/c0t0d0s6 ufs fsck: sanity check: /dev/rdsk/c0t0d0s6 needs checking |
How to Check File Systems Interactively
Become superuser or assume an equivalent role.
Unmount the local file systems except root (/) and /usr.
# umountall -l
Check the file systems.
# fsck
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/device-name as arguments to the fsck command. Any inconsistency messages are displayed.
For information about how to respond to the error message prompts while interactively checking one or more UFS file systems, see "Resolving UFS File System Inconsistencies (Tasks)" in System Administration Guide: Advanced Administration.
Caution - Running the fsck command on a mounted file
system might cause a system to crash if the fsck command
makes any changes, unless stated otherwise, such as running the fsck command in single-user mode to repair a file system.If you corrected any errors, type fsck and press Return.
The fsck command might be unable to fix all errors in one execution. If you see the message FILE SYSTEM STATE NOT SET TO OKAY, run the command again. If that does not work, see "Fixing a UFS File System That the fsck Command Cannot Repair".
Rename and move any files put in the lost+found directory.
Individual files put in the lost+found directory by the fsck command are renamed with their inode numbers. 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 the file command to identify file types. When whole directories are put into the lost+found directory, it is easier to figure out where they belong and to move them back.
Example--Checking File Systems Interactively
The following example shows how to check the /dev/rdsk/c0t0d0s6 file system and corrects the incorrect block count.
# 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 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 ***** |
Preening UFS File Systems
The fsck -o p command (p is for preen) checks UFS file systems and automatically fixes the problems that normally result from an unexpected system shutdown. This command exits immediately if it encounters a problem that requires operator intervention. This command also permits parallel checking of file systems.
You can run the fsck -o p command to preen the file systems after an unclean shutdown. In this mode, the fsck command does not look at the clean flag and does a full check. These actions are a subset of the actions that the fsck command takes when it runs interactively.
How to Preen a UFS File System
Unmount the UFS file system.
# umount /mount-point
Check the UFS file system with the preen option.
# fsck -o p /dev/rdsk/device-name
You can preen individual file systems by using /mount-point or /dev/rdsk/device-name as arguments to the fsck command.
Example--Preening a UFS File System
The following example shows how to preen the /usr file system.
# fsck -o p /usr |
Fixing a UFS File System That the fsck Command Cannot Repair
Sometimes, you need to run the fsck command a few times to fix a file system because problems corrected on one pass might uncover other problems not found in earlier passes. The fsck command does not keep running until it comes up clean, so you must rerun it manually.
Pay attention to the information displayed by the fsck command. This information might help you fix the problem. For example, the messages might point to a damaged directory. If you delete the directory, you might find that the fsck command runs cleanly.
If the fsck command still cannot repair the file system, you can try to use the fsdb, ff, clri, and ncheck commands to figure out and fix what is wrong. For information about how to use these commands, see fsdb(1M), ff(1M), clri(1M), and ncheck(1M). You might, ultimately, need to re-create the file system and restore its contents from backup media.
For information about restoring complete file systems, see Chapter 48, Restoring Files and File Systems (Tasks).
If you cannot fully repair a file system but you can mount it read-only, try using the cp, tar, or cpio commands to retrieve all or part of the data from the file system.
If hardware disk errors are causing the problem, you might need to reformat and divide the disk into slices again before re-creating and restoring file systems. Hardware errors usually display the same error again and again across different commands. The format command tries to work around bad blocks on the disk. If the disk is too severely damaged, however, the problems might persist, even after reformatting. For information about using the format command, see format(1M). For information about installing a new disk, see Chapter 33, SPARC: Adding a Disk (Tasks) or Chapter 34, IA: Adding a Disk (Tasks).
Restoring a Bad Superblock
When the superblock of a file system becomes damaged, you must restore it. The fsck command tells you when a superblock is bad. Fortunately, copies of the superblock are stored within a file system. You can use the fsck -o b command to replace the superblock with one of the copies.
For more information about the superblock, see "The Superblock".
If the superblock in the root (/) file system becomes damaged and you cannot restore it, you have two choices:
Reinstall the system
Boot from the network or local CD, and attempt the following steps. If these steps fail, recreate the root (/) file system with the newfs command and restore it from a backup copy.
How to Restore a Bad Superblock
Become superuser or assume an equivalent role.
Determine whether the bad superblock is in the root (/) or /usr file system and select one of the following:
Stop the system and boot from the network or a locally-connected CD if the bad superblock is in the root (/) or /usr file system.
From a locally-connected CD, use the following command:
ok boot -s cdrom
From the network where a boot or install server is already setup, use the following command:
ok boot -s net
If you need help stopping the system, see "SPARC: How to Stop the System for Recovery Purposes" or "IA: How to Stop a System for Recovery Purposes".
Change to a directory outside the damaged file system and unmount the file system if the bad superblock is not in the root (/) or /usr file system.
# umount /mount-point
Caution - Be sure to use the newfs -N in the next
step. If you omit the -N option, you will create a new, empty
file system.
Display the superblock values with the newfs -N command.
# newfs -N /dev/rdsk/device-name
The output of this command displays the block numbers that were used for the superblock copies when the newfs command created the file system, unless the file system was created with special parameters. For information on creating a customized file system, see "Custom File System Parameters".
Provide an alternate superblock with the fsck command.
# fsck -F ufs -o b=block-number /dev/rdsk/device-name
The fsck command uses the alternate superblock you specify to restore the primary superblock. You can always try 32 as an alternate block, or use any of the alternate blocks shown by the newfs -N command.