Skip Navigation Links | |
Exit Print View | |
![]() |
System Administration Guide: Devices and File Systems Oracle Solaris 10 8/11 Information Library |
1. Managing Removable Media (Overview)
2. Managing Removable Media (Tasks)
3. Accessing Removable Media (Tasks)
4. Writing CDs and DVDs (Tasks)
5. Managing Devices (Overview/Tasks)
6. Dynamically Configuring Devices (Tasks)
7. Using USB Devices (Overview)
9. Using InfiniBand Devices (Overview/Tasks)
11. Administering Disks (Tasks)
12. SPARC: Setting Up Disks (Tasks)
13. x86: Setting Up Disks (Tasks)
14. Configuring Oracle Solaris iSCSI Targets and Initiators (Tasks)
15. The format Utility (Reference)
16. Managing File Systems (Overview)
17. Creating and Mounting File Systems (Tasks)
18. Using The CacheFS File System (Tasks)
19. Configuring Additional Swap Space (Tasks)
20. Checking UFS File System Consistency (Tasks)
How the UFS File System State Is Recorded
What the fsck Command Checks and Tries to Repair
Why UFS File System Inconsistencies Might Occur
UFS Components That Are Checked for Consistency
File System Size and Inode List Size Checks
Incorrect "." and ".." Entry Checks
Interactively Checking and Repairing a UFS File System
How to Check the UFS root (/), /usr, or /var File Systems From an Alternate Boot Device
How to Check Other UFS File Systems (Not root (/), /usr, or /var)
How to Preen a UFS File System
Fixing a UFS File System That the fsck Command Cannot Repair
Restoring a Bad UFS Superblock
How to Restore a Bad UFS Superblock (Solaris 10 6/06 Release)
How to Restore a Bad Superblock (Solaris 8, 9, and 10 Releases)
Syntax and Options for the fsck Command
21. UFS File System (Reference)
22. Backing Up and Restoring UFS File Systems (Overview)
23. Backing Up UFS Files and File Systems (Tasks)
24. Using UFS Snapshots (Tasks)
25. Restoring UFS Files and File Systems (Tasks)
26. UFS Backup and Restore Commands (Reference)
27. Copying Files and File Systems (Tasks)
You might need to interactively check file systems in the following instances:
When they cannot be mounted
When they develop inconsistencies while in use
When an in-use file system develops inconsistencies, error messages might be displayed in the console window or the system messages file. Or, the system might crash. For example, the system messages file, /var/adm/messages, might include messages similar to the following:
Sep 5 13:42:40 hostname ufs: [ID 879645 kern.notice] NOTICE: /: unexpected free inode 630916, run fsck(1M)
hostname is the system reporting the error.
Before using the fsck command, you might want to refer to these references for information on resolving fsck error messages:
Keep the following points in mind when running the fsck command to check UFS file systems:
A file system should be inactive when you use fsck to check a file system. File system changes waiting to be flushed to disk or file system changes that occur during the fsck checking process can be interpreted as file system corruption. These issues may not be a reliable indication of a problem.
A file system must be inactive when you use fsck to repair that file system. File system changes waiting to be flushed to disk or file system changes that occur during the fsck repairing process might cause the file system to become corrupted. Or, they might cause the system to crash.
Unmount a file system before you use fsck on that file system. Doing so ensures that the file system data structures are consistent as possible. The only exceptions are for the active root (/), /usr, and /var file systems because they must be mounted to run fsck.
If you need to repair the root (/), /usr, and /var file systems, boot the system from an alternate device, if possible, so that these file systems are unmounted and inactive.
For step-by-step instructions on running fsck on the root (/), /usr, or /var file systems, see How to Check the UFS root (/), /usr, or /var File Systems From an Alternate Boot Device.
For new information about fsck in the Solaris 10 6/06 release, see Enhancements to UFS File System Utilities (fsck, mkfs, and newfs). There is no need to rerun fsck if you see the following message:
***** FILE SYSTEM WAS MODIFIED *****
However, it doesn't harm the file system to rerun fsck after this message. This message is just informational about fsck's corrective actions.
This procedure assumes that a local Solaris DVD or network boot server is available so that you can boot the system from an alternate device.
For information on restoring a bad superblock, see How to Restore a Bad UFS Superblock (Solaris 10 6/06 Release) or How to Restore a Bad Superblock (Solaris 8, 9, and 10 Releases).
For information on detaching the root (/) mirror, see Working With Submirrors in Solaris Volume Manager Administration Guide.
You'll need to supply this device name when booted from an alternate device. Identifying this device when you are already booted from the alternate device is more difficult.
Doing so ensures that there is no activity on these file systems.
For example:
# init 0 ok boot net -s . . . #
If the hardware for the file system to be checked or repaired has changed, the device names might have changed. Check that the fsck -n message Last Mounted on ... indicates the expected device for the file system.
In this example, the root (/) file system to be checked is /dev/dsk/c0t0d0s0.
# fsck -n /dev/rdsk/c0t0d0s0 ** /dev/rdsk/c0t0d0s0 (NO WRITE) ** Last Mounted on / . . . fsck /dev/rdsk/c0t0d0s0 ** /dev/rdsk/c0t0d0s0 ** Last Mounted on / ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames . . .
For information on how to respond to the error message prompts while you interactively check one or more UFS file systems, see Chapter 20, Resolving UFS File System Inconsistencies (Tasks), in System Administration Guide: Advanced Administration.
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. Try to use the grep command to match phrases within individual files and the file command to identify file types.
Eventually, remove unidentifiable files or directories left in the lost+found directory so that it doesn't fill up unnecessarily.
# init 6
For new information about fsck in the Solaris 10 6/06 release, see Enhancements to UFS File System Utilities (fsck, mkfs, and newfs). There is no need to rerun fsck if you see the following message:
***** FILE SYSTEM WAS MODIFIED *****
However, it doesn't harm the file system to rerun fsck after this message. This message is just informational about fsck's corrective actions.
This procedure assumes that the file system to be checked is unmounted.
For information on restoring a bad superblock, see How to Restore a Bad UFS Superblock (Solaris 10 6/06 Release) or How to Restore a Bad Superblock (Solaris 8, 9, and 10 Releases).
Specify the mount point directory or /dev/dsk/device-name as arguments to the fsck command. Any inconsistency messages are displayed.
For example:
# umount /export/home # fsck /dev/rdsk/c0t0d0s7 ** /dev/dsk/c0t0d0s7 ** Last Mounted on /export/home . . .
For information on how to respond to the error message prompts while you interactively check one or more UFS file systems, see Chapter 20, Resolving UFS File System Inconsistencies (Tasks), in System Administration Guide: Advanced Administration.
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. Try to use the grep command to match phrases within individual files and the file command to identify file types.
Eventually, remove unidentifiable files or directories left in the lost+found directory so that it doesn't fill up unnecessarily.
Example 20-1 Interactively Checking UFS Non-root (/) or Non-/usr File Systems
The following example shows how to check the /dev/rdsk/c0t0d0s6 file system and correct the incorrect block count. This example assumes that the file system is unmounted.
# fsck /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) ***** FILE SYSTEM WAS MODIFIED ***** #
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.
This procedure assumes that the file system is unmounted or inactive.
# umount /mount-point
# 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 20-2 Preening a UFS File System
The following example shows how to preen the /export/home file system.
# fsck -o p /export/home
The fsck command operates in several passes, and a problem corrected in a later pass can expose other problems that are only detected by earlier passes. Therefore, it is sometimes necessary to run fsck until it no longer reports any problems. Doing so ensures that all errors have been found and repaired.
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, try to use the ff, clri, and ncheck commands to figure out and fix what is wrong. For information about how to use these commands, see the following references:
Ultimately, you might need to re-create the file system and restore its contents from backup media.
For information about restoring complete file systems, see Chapter 25, Restoring UFS 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 repartition the disk again before re-creating and restoring file systems. Check that the device cables and connectors are functional before replacing the disk device. 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. However, if the disk is too severely damaged, 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 12, SPARC: Setting Up Disks (Tasks) or Chapter 13, x86: Setting Up Disks (Tasks).