File System Response to Problems

When the file system encounters problems, it responds in one of three ways:

• Marks an inode bad
• Disables transactions
• Disables the file system

Marking an Inode Bad

Inodes can be marked bad if an inode update or a directory-block update fails. In these types of failures, the file system does not know what information is on the disk, and considers all the information that it finds to be invalid. After an inode is marked bad, the kernel still permits access to the file name, but any attempt to access the data in the file or change the inode fails.

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:

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).