VERITAS File System 4.1 Administrator's Guide

Kernel Messages
Kernel Messages
Appendix B204
Disabling Transactions
If the file system detects an error while writing the intent log, it disables transactions. After
transactions are disabled, the files in the file system can still be read or written, but no block
or inode frees or allocations, structural changes, directory entry changes, or other changes to
metadata are allowed.
Disabling a File System
If an error occurs that compromises the integrity of the file system, VxFS disables itself. If the
intent log fails or an inode-list error occurs, the super-block is ordinarily updated (setting the
VX_FULLFSCK flag) so that the next fsck does a full structural check. If this super-block
update fails, any further changes to the file system can cause inconsistencies that are
undetectable by the intent log replay. To avoid this situation, the file system disables itself.
Recovering a Disabled File System
When the file system is disabled, no data can be written to the disk. Although some minor file
system operations still work, most simply return EIO. The only thing that can be done when
the file system is disabled is to do a umount and run a full fsck.
Although a log replay may produce a clean file system, do a full structural check to be safe. To
execute a full structural check, enter:
# fsck -F vxfs -o full -y /dev/vx/rdsk/diskgroup/volume
NOTE Be careful when running this command. By specifying the -y option, all fsck
user prompts are answered with a yes, which can make irreversible changes if
it performs a full file system check.
The file system usually becomes disabled because of disk errors. Disk failures that disable a
file system should be fixed as quickly as possible (see the fsck_vxfs(1M) manual page).
Kernel Messages
This section lists the VxFS kernel error messages in numerical order. The Description
subsection for each message describes the problem, the Action subsection suggests possible
solutions.
Global Message IDs
When a VxFS kernel message displays on the system console, it is preceded by a numerical ID
shown in the msgcnt field. This ID number increases with each instance of the message to
guarantee that the sequence of events is known when analyzing file system problems.