SUNWcsu
fsck audits and interactively repairs inconsistent conditions on file systems. A file system to be checked may be specified by giving the name of the block or character special device or by giving the name of its mount point if a matching entry exists in /etc/vfstab.
special represents
the character special device, for example, /dev/rdsk/c1d0s7, on which the
file system resides. Note: the character special device, not the block special
device should be used.
fsck will not work on a block device if the block device is mounted,
unless the file system is error-locked.
If no special device is specified, all ufs file systems specified in the vfstab with a fsckdev entry will be checked. If the -p (‘‘preen’’) option is specified, ufs file systems with an fsckpass number greater than 1 are checked in parallel. See fsck(1M) .
In the case of correcting serious inconsistencies, by default, fsck asks for confirmation before making a repair and waits for the operator to respond either yes or no. If the operator does not have write permission on the file system, fsck will default to a -n (no corrections) action. See fsck(1M) .
Repairing some file system inconsistencies may result in loss of data. The amount and severity of data loss may be determined from the diagnostic output.
fsck automatically corrects innocuous inconsistencies such as unreferenced inodes, too-large link counts in inodes, missing blocks in the free list, blocks appearing in the free list and also in files, or incorrect counts in the super block. It displays a message for each inconsistency corrected that identifies the nature of the correction on the file system which took place. After successfully correcting a file system, fsck prints the number of files on that file system, the number of used and free blocks, and the percentage of fragmentation.
Inconsistencies checked are as follows:
- Blocks claimed by more than one inode or the free list.
- Blocks claimed by an inode or the free list outside the range of the file system.
- Incorrect link counts.
- Incorrect directory sizes.
- Bad inode format.
- Blocks not accounted for anywhere.
- Directory checks, file pointing to unallocated inode, inode number out of range, and absence of ‘.’ and ‘..’ as the first two entries in each directory.
- Super Block checks: more blocks for inodes than there are in the file system.
- Bad free block list format.
- Total free block and/or free inode count incorrect.
Orphaned files and directories (allocated but unreferenced) are, with the operator’s concurrence, reconnected by placing them in the lost+found directory. The name assigned is the inode number. If the lost+found directory does not exist, it is created. If there is insufficient space in the lost+found directory, its size is increased.
The generic-options consist of the following options:
See generic fsck(1M) for the details for specifying special.
The operating system buffers file system data. Running fsck on a mounted file system can cause the operating system’s buffers to become out of date with respect to the disk. For this reason, the file system should be unmounted when fsck is used. If this is not possible, care should be taken that the system is quiescent and that it is rebooted immediately after fsck is run. Quite often, however, this will not be sufficient. A panic will probably occur if running fsck on a file system modifies the file system.
Running fsck on file systems larger than 2 Gb fails if the user chooses to use the block interface to the device:
rather than the raw (character special) device:
- fsck /dev/dsk/c?t?d?s?
- fsck /dev/rdsk/c?t?d?s?