Filesystem check phases (HTFS, EAFS, AFS, S51K)

When you check and repair a filesystem, the fsck(ADM) utility scans and examines the filesystem structures, reporting on its progress with these messages:

   ** Phase 0 - Replay Log
   ** Phase 1 - Check Blocks and Sizes
   ** Phase 1b - Rescan For More DUPS
   ** Phase 2 - Check Pathnames
   ** Phase 3 - Check Connectivity
   ** Phase 4 - Check Reference Counts
   ** Phase 5 - Check Free List Bitmap
   ** Phase 6 - Salvage Free List Bitmap

Each phase compares components and checks that these components agree with each other.

Phase 0

If intent logging is enabled on the filesystem and a full check is not requested, a ``fast check'' is performed. This completes outstanding transactions found in the filesystem log and marks the filesystem clean. The remaining phases are skipped in this instance.

Phase 1

In Phase 1, fsck reads the inode table to determine sizes and locates the blocks used by each file. Inodes are checked for inode type, zero link counts, inode sizes, and bad or duplicate blocks. (Bad blocks are block values outside the boundaries of a filesystem; a duplicate block means that two inodes point to the same block on the disk.) When fsck clears an inode, it removes the bad information in the inode, which removes the file or directory that is associated with it. fsck also confirms the filesystem fits on the associated device. fsck attempts to locate the original and duplicate inodes for correction in Phase 2.

Phase 1b

If duplicate blocks were found, the filesystem is scanned once again.

Phase 2

In Phase 2, fsck cleans up error conditions caused by improper inode status, out-of-range inode pointers, and directories that point to bad inodes. Files removed in Phase 1 must also have their directory entries removed. If files with duplicate blocks are found in Phase 1, fsck removes both files.

Phase 3

In Phase 3, fsck checks for directory connectivity and reconnects files that were severed from the directory structure. Any files that are unreferenced but still valid are placed in the special lost+found directory in the root directory of the filesystem. For root, this directory is /lost+found. When the directory is severed, the name of the file is lost, so fsck assigns a new name, the inode number of the file. See about inodes for a description of inodes.

---

NOTE: fsck does not create or extend the lost+found directory. There must already be a sufficient number of empty slots in the directory for use by fsck when reconnecting files. When you add filesystem mount configuration with the Filesystem Manager, you can direct it to create a lost+found directory if none exists. See ``Check and repair options''.

---

Phase 4

In Phase 4, fsck checks the link count of each entry that survived Phases 2 and 3. In some cases, files that were not referenced under the directory structure, but still have an inode, can be relinked to the filesystem in /lost+found. Inodes that cannot be recovered are cleared.

Phase 5

In Phase 5, fsck examines the free-block list maintained by the filesystem and resolves the missing or unallocated blocks allocated or removed earlier. When an inconsistency is detected, fsck rebuilds the free-block list.

Phase 6

If specified in Phase 5, fsck(ADM) reconstructs a free-block list from the altered filesystem during Phase 6.

For a complete list of error messages, see the fsck(ADM) manual page.

See also:

• ``Checking and repairing filesystems''

• ``Check and repair options''