Common VxFS error messages
This article shows a list of typical JFS (vxfs) error messages that may appear on /var/adm/syslog/syslog.log file or the system console. Very often, the fsck command will be required to clean the affected VxFS metadata structures, with the possibility of losing data. Backing storage or disk replacement may be required if the root cause is a damage disk drives.
Oct 1 22:08:29 dsbb vmunix: msgcnt 1 vxfs: mesg 037: vx_metaioerr - vx_dirlook0
A read or a write error occurred while accessing file system metadata. The full fsck flag on the file system was set. The message specifies whether the disk I/O that failed was a read or a write.
File system metadata includes inodes, directory blocks, and the file system log. If the error was a write error, it is likely that some data was lost. This message should be accompanied by another file system message describing the particular file system metadata affected, as well as a message from the disk driver containing information about the disk I/O error.
Action to take
Resolve the condition causing the disk error. If the error was the result of a temporary condition (such as accidentally turning off a disk or a loose cable), correct the condition. Check for loose cables, etc. Unmount the file system and use fsck to run a full structural check (possibly with loss of data).
In case of an actual disk error, if it was a read error and the disk driver remaps bad sectors on write, it may be fixed when fsck is run since fsck is likely to rewrite the sector with the read error. In other cases, you replace or reformat the disk drive and restore the file system from backups. Consult the documentation specific to your system for information on how to recover from disk errors. The disk driver should have printed a message that may provide more information.
Oct 1 22:08:29 dsbb vmunix: msgcnt 3 vxfs: mesg 008: vx_direrr: vx_dirlook_4 -6
A directory operation failed in an unexpected manner. The mount point,inode and block number identify the failing directory. If the inode is an immediate directory, the directory entries are stored in the inode, so no block number is reported. If the error is ENOENT or ENOTDIR, an inconsistency was detected in the directory block. This inconsistency could be a bad free count, a corrupted hash chain or any similar directory structure error. If the error is EIO or ENXIO, an I/O failure occurred while reading or writing the disk block.
Action to take
Because the VX_FULLFSCK flag is set in the super-block, a full FSCK is required to fix the structure of the file system.
In this example, the error number is "6" which when looked up in /usr/include/sys/errno.h. it translates to:
- define ENXIO 6 /* No such device or address */
Very often ENXIO is caused by intermittent hardware problems and those should be investigated before taking any corrective action with the file system.
Oct 1 22:08:53 dsbb vmunix: msgcnt 4 vxfs: mesg 017: vx_dirlook - / file system
When inode information is no longer dependable, the kernel marks it bad on disk. The most common reason for marking an inode bad is a disk I/O failure. If there is an I/O failure in the inode list, on a directory block, or an indirect address extent, the integrity of the data in the inode, or the data the kernel tried to write to the inode list, is questionable. In these cases, the disk driver prints an error message and one or more inodes are marked bad.
The kernel also marks an inode bad if it finds a bad extent address, invalid inode fields, or corruption in directory data blocks during a validation check. A validation check failure indicates the file system has been corrupted. This usually occurs because a user or process has written directly to the device or used fsdb to change the file system.
The VX_FULLFSCK flag is set in the super-block so fsck will do a full structural check the next time it is run.
Action to take
Check the console log for I/O errors. If the problem is a disk failure, replace the disk. If the problem is not related to an I/O failure, find out how the disk became corrupted. If no user or process is writing to the device, report the problem to your customer support organization. In either case, unmount the file system and use fsck to run a full structural check.