Filesystem check phases (HTFS, EAFS, AFS, S51K)
When you check and repair a filesystem, the
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
DTFS filesystem check phases are different. See
``Filesystem check phases (DTFS)''
for more information.
Each phase compares components and checks that
these components agree with each other.
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.
In Phase 1,
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.)
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
attempts to locate the original and duplicate inodes for correction in Phase 2.
If duplicate blocks were found, the filesystem is scanned once again.
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.
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.
for a description of inodes.
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
you can direct it to create a lost+found directory if none exists.
``Check and repair options''.
In Phase 4,
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.
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,
rebuilds the free-block list.
If specified in Phase 5,
reconstructs a free-block list from the altered filesystem during Phase 6.
For a complete list of error messages, see the
Filesystem check phases (DTFS)
Check and repair options
© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003