Home > Veritas Storage Foundation™ File System Manual Pages
fsck [-V vxfs ] [ -mNnYy ] [ -o full,nolog,mounted ] special...
special specifies one or more special character devices, for example, /dev/vx/rdsk/rlv01.
If multiple devices are specified, each device is checked in turn unless the -o p suboption is also specified, in which case the devices are checked in parallel.
Be careful when accessing shared volumes with other utilities, such as dd, that can write data to disk. It is possible to destroy data being accessed from other nodes.
- -V vxfs
- Specifies the VxFS file system type.
- Reports whether the file system was marked clean and returns an exit code. A zero indicates the file system is clean, a 32 indicates that the file system needs checking. This option does not validate the file system.
- -n | N
- Assumes a no response to all prompts by fsck. Does not open the file system for writing, does not replay the intent log, and performs a full file system check. Use this option to test for file system corruption.
- -y | Y
- Assumes a yes response to all prompts by fsck. Additionally, if the file system requires a full file system check after the log replay, or if the nolog suboption causes the log replay to be skipped and the file system is not clean, a full file system check is performed.
- Specifies VxFS file system-specific options. These options can be a combination of the following in a comma-separated list:
- Performs a full file system check.
- -o mounted is only used internally as part of the primary cluster node recovery process after the primary fails. Never enter this option from the command line as it can destroy a file system if not used correctly.
- Does not perform a log replay. Use this option only if the log area was physically damaged or fsck cannot read the log's layout.
Note: Use the -n option to verify whether there are file system inconsistencies. Use fsck -o full,nolog to fix a corrupted file system and avoid a log replay. If you run fsck -o full without nolog on a clean file system, it replays the intent log and performs a full file system check.
- Allows parallel log replay for several VxFS file systems. Each message from fsck is prefixed with the device name to identify the device. This suboption does not perform a full file system check in parallel; that is still done sequentially on each device, even when multiple devices are specified. This option is compatible only with the -y|Y option (that is, non-interactive full file system check), in which case a log replay is done in parallel on all specified devices. A sequential full file system check is performed on devices where needed. The number of devices that can be checked in parallel is determined by the amount of physical memory in the system. One instance of fsck on a single device can consume up to a maximum of 32 megabytes of memory.
Because VxFS maintains an intent log, a complete check is generally not required. The default is to perform an intent log replay only. If fsck or the log replay detects file system damage, an indication that a complete check is required is placed in the super-block. In this case, if you specified the -y option, the full check runs after the log replay. If you did not specify the -y option, run fsck -o full to perform the full structural check.
A full check looks for these inconsistencies:
- Blocks claimed by more than one inode on the free list.
- Blocks claimed by an inode outside the range of the file system.
- Incorrect link counts.
- Size checks:
Incorrect number of blocks.
Directory entry format.
- Bad inode format.
- Blocks not accounted for anywhere.
- Directory checks:
File pointing to unallocated inode.
Inode number out of range.
Linkage to parent directory.
Hash chain linkage.
Free space count.
- Super-block checks:
More blocks for inodes than there are in the file system.
- Structural Files (VxFS Version 4 and higher layouts):
Object Location Table (OLT).
Inode list files.
Inode allocation summary files.
Attribute files (including Access Control Lists).
Attribute link counts.
- Bad free block list format.
- Total free block and/or free inode count incorrect.
Orphaned files and directories (allocated but unreferenced) are, with the user's agreement, reconnected by placing them in the lost+found directory. The name assigned is the inode number. The only restriction is that the directory lost+found must already exist in the file system's root directory.
The following return codes are used for the -m option:
- The file system is unmounted and clean.
- The file system is unmounted and needs checking.
- The file system is mounted.
- The stat of the device failed.
- The state could not be determined because of an error.
In most cases, fsck prints the following messages:
log replay in progress replay complete - marking super-block as CLEAN
If the file system is already clean, fsck prints the following message instead:
file system is clean - log replay is not required
If fsck prints any other messages, a full structural check is needed. If the -y option is specified, fsck performs (if necessary) a full check after running the intent log replay. If the -y option is not used, fsck must be invoked with the -o full option to perform a full structural check.
If -o p is specified, fsck prints the following messages for a device, for example /dev/vx/rdsk/rlv00:
/dev/vx/rdsk/rlv00: log replay in progress /dev/vx/rdsk/rlv00: replay complete - marking super-block as CLEAN
Unlike 2.x and earlier releases of VxFS, a full file system check does not always perform pending extended inode operations. Some extended operations can only be processed when the file system is mounted. A file system that has been marked CLEAN can still contain extended operations.
If a structural flaw is detected during the intent log replay, the full fsck flag is set on the file system without operator interaction.
If fsck encounters a large file on an older OS version, the command stops without completing the file system check.
Last updated: 01 April 2006
Copyright ©2009 Symantec Corporation
All rights reserved.