fsck_ffs - The UNIX|- Filesystem Check Program
Marshall Kirk McKusick
Computer Systems Research Group
Computer Science Division
Department of Electrical Engineering and Computer Science
University of California, Berkeley
Berkeley, CA 94720
T. J. Kowalski
Bell Laboratories
Murray Hill, New Jersey 07974
ABSTRACT
This document reflects the use of fsck_ffs
with the 4.2BSD and 4.3BSD filesystem organiza-
tion. This is a revision of the original paper
written by T. J. Kowalski.
Filesystem Check Program (fsck_ffs) is an
interactive filesystem check and repair program.
Fsck_ffs uses the redundant structural information
in the UNIX filesystem to perform several con-
sistency checks. If an inconsistency is detected,
it is reported to the operator, who may elect to
fix or ignore each inconsistency. These incon-
sistencies result from the permanent interruption
of the filesystem updates, which are performed
every time a file is modified. Unless there has
been a hardware failure, fsck_ffs is able to
repair corrupted filesystems using procedures
based upon the order in which UNIX honors these
filesystem update requests.
The purpose of this document is to describe
the normal updating of the filesystem, to discuss
the possible causes of filesystem corruption, and
_________________________
-UNIX is a trademark of Bell Laboratories.
This work was done under grants from the National Sci-
ence Foundation under grant MCS80-05144, and the
Defense Advance Research Projects Agency (DoD) under
Arpa Order No. 4031 monitored by Naval Electronic Sys-
tem Command under Contract No. N00039-82-C-0235.
SMM:3-2 The UNIX Filesystem Check Program
to present the corrective actions implemented by
fsck_ffs. Both the program and the interaction
between the program and the operator are
described.
Revised July 16, 1985
The UNIX Filesystem Check Program SMM:3-3
TABLE OF CONTENTS
1. Introduction
2. Overview of the filesystem
2.1. Superblock
2.2. Summary Information
2.3. Cylinder groups
2.4. Fragments
2.5. Updates to the filesystem
3. Fixing corrupted filesystems
3.1. Detecting and correcting corruption
3.2. Super block checking
3.3. Free block checking
3.4. Checking the inode state
3.5. Inode links
3.6. Inode data size
3.7. Checking the data associated with an inode
3.8. Filesystem connectivity
Acknowledgements
References
4. Appendix A
4.1. Conventions
4.2. Initialization
4.3. Phase 1 - Check Blocks and Sizes
4.4. Phase 1b - Rescan for more Dups
4.5. Phase 2 - Check Pathnames
4.6. Phase 3 - Check Connectivity
4.7. Phase 4 - Check Reference Counts
4.8. Phase 5 - Check Cyl groups
4.9. Cleanup
SMM:3-4 The UNIX Filesystem Check Program
1. Introduction
This document reflects the use of fsck_ffs with the
4.2BSD and 4.3BSD filesystem organization. This is a revi-
sion of the original paper written by T. J. Kowalski.
When a UNIX operating system is brought up, a con-
sistency check of the filesystems should always be per-
formed. This precautionary measure helps to insure a reli-
able environment for file storage on disk. If an incon-
sistency is discovered, corrective action must be taken.
Fsck_ffs runs in two modes. Normally it is run non-
interactively by the system after a normal boot. When run-
ning in this mode, it will only make changes to the filesys-
tem that are known to always be correct. If an unexpected
inconsistency is found fsck_ffs will exit with a non-zero
exit status, leaving the system running single-user. Typi-
cally the operator then runs fsck_ffs interactively. When
running in this mode, each problem is listed followed by a
suggested corrective action. The operator must decide
whether or not the suggested correction should be made.
The purpose of this memo is to dispel the mystique sur-
rounding filesystem inconsistencies. It first describes the
updating of the filesystem (the calm before the storm) and
then describes filesystem corruption (the storm). Finally,
the set of deterministic corrective actions used by fsck_ffs
(the Coast Guard to the rescue) is presented.
2. Overview of the filesystem
The filesystem is discussed in detail in [Mckusick84];
this section gives a brief overview.
2.1. Superblock
A filesystem is described by its super-block. The
super-block is built when the filesystem is created
(newfs(8)) and never changes. The super-block contains the
basic parameters of the filesystem, such as the number of
data blocks it contains and a count of the maximum number of
files. Because the super-block contains critical data, newfs
replicates it to protect against catastrophic loss. The
default super block always resides at a fixed offset from
the beginning of the filesystem's disk partition. The redun-
dant super blocks are not referenced unless a head crash or
other hard disk error causes the default super-block to be
unusable. The redundant blocks are sprinkled throughout the
disk partition.
Within the filesystem are files. Certain files are dis-
tinguished as directories and contain collections of
pointers to files that may themselves be directories. Every
file has a descriptor associated with it called an inode.
The UNIX Filesystem Check Program SMM:3-5
The inode contains information describing ownership of the
file, time stamps indicating modification and access times
for the file, and an array of indices pointing to the data
blocks for the file. In this section, we assume that the
first 12 blocks of the file are directly referenced by
values stored in the inode structure itself-. The inode
structure may also contain references to indirect
blocks containing further data block indices. In a
filesystem with a 4096 byte block size, a singly
indirect block contains 1024 further block addresses, a
doubly indirect block contains 1024 addresses of
further single indirect blocks, and a triply indirect
block contains 1024 addresses of further doubly
indirect blocks (the triple indirect block is never
needed in practice).
In order to create files with up to 2^32 bytes, using
only two levels of indirection, the minimum size of a
filesystem block is 4096 bytes. The size of filesystem
blocks can be any power of two greater than or equal to
4096. The block size of the filesystem is maintained in the
super-block, so it is possible for filesystems of different
block sizes to be accessible simultaneously on the same sys-
tem. The block size must be decided when newfs creates the
filesystem; the block size cannot be subsequently changed
without rebuilding the filesystem.
2.2. Summary information
Associated with the super block is non replicated sum-
mary information. The summary information changes as the
filesystem is modified. The summary information contains the
number of blocks, fragments, inodes and directories in the
filesystem.
2.3. Cylinder groups
The filesystem partitions the disk into one or more
areas called cylinder groups. A cylinder group is comprised
of one or more consecutive cylinders on a disk. Each
cylinder group includes inode slots for files, a block map
describing available blocks in the cylinder group, and sum-
mary information describing the usage of data blocks within
the cylinder group. A fixed number of inodes is allocated
for each cylinder group when the filesystem is created. The
current policy is to allocate one inode for every 2048 bytes
of disk space; this is expected to be far more inodes than
will ever be needed.
All the cylinder group bookkeeping information could be
_________________________
-The actual number may vary from system to system, but
is usually in the range 5-13.
SMM:3-6 The UNIX Filesystem Check Program
placed at the beginning of each cylinder group. However if
this approach were used, all the redundant information would
be on the top platter. A single hardware failure that des-
troyed the top platter could cause the loss of all copies of
the redundant super-blocks. Thus the cylinder group book-
keeping information begins at a floating offset from the
beginning of the cylinder group. The offset for the i+1st
cylinder group is about one track further from the beginning
of the cylinder group than it was for the ith cylinder
group. In this way, the redundant information spirals down
into the pack; any single track, cylinder, or platter can be
lost without losing all copies of the super-blocks. Except
for the first cylinder group, the space between the begin-
ning of the cylinder group and the beginning of the cylinder
group information stores data.
2.4. Fragments
To avoid waste in storing small files, the filesystem
space allocator divides a single filesystem block into one
or more fragments. The fragmentation of the filesystem is
specified when the filesystem is created; each filesystem
block can be optionally broken into 2, 4, or 8 addressable
fragments. The lower bound on the size of these fragments is
constrained by the disk sector size; typically 512 bytes is
the lower bound on fragment size. The block map associated
with each cylinder group records the space availability at
the fragment level. Aligned fragments are examined to deter-
mine block availability.
On a filesystem with a block size of 4096 bytes and a
fragment size of 1024 bytes, a file is represented by zero
or more 4096 byte blocks of data, and possibly a single
fragmented block. If a filesystem block must be fragmented
to obtain space for a small amount of data, the remainder of
the block is made available for allocation to other files.
For example, consider an 11000 byte file stored on a
4096/1024 byte filesystem. This file uses two full size
blocks and a 3072 byte fragment. If no fragments with at
least 3072 bytes are available when the file is created, a
full size block is split yielding the necessary 3072 byte
fragment and an unused 1024 byte fragment. This remaining
fragment can be allocated to another file, as needed.
2.5. Updates to the filesystem
Every working day hundreds of files are created, modi-
fied, and removed. Every time a file is modified, the
operating system performs a series of filesystem updates.
These updates, when written on disk, yield a consistent
filesystem. The filesystem stages all modifications of crit-
ical information; modification can either be completed or
cleanly backed out after a crash. Knowing the information
that is first written to the filesystem, deterministic
The UNIX Filesystem Check Program SMM:3-7
procedures can be developed to repair a corrupted filesys-
tem. To understand this process, the order that the update
requests were being honored must first be understood.
When a user program does an operation to change the
filesystem, such as a write, the data to be written is
copied into an internal in-core buffer in the kernel. Nor-
mally, the disk update is handled asynchronously; the user
process is allowed to proceed even though the data has not
yet been written to the disk. The data, along with the inode
information reflecting the change, is eventually written out
to disk. The real disk write may not happen until long after
the write system call has returned. Thus at any given time,
the filesystem, as it resides on the disk, lags the state of
the filesystem represented by the in-core information.
The disk information is updated to reflect the in-core
information when the buffer is required for another use,
when a sync(2) is done (which happens automatically at 30
second intervals through a kernel thread), or by manual
operator intervention with the sync(8) command. If the sys-
tem is halted without writing out the in-core information,
the filesystem on the disk will be in an inconsistent state.
If all updates are done asynchronously, several serious
inconsistencies can arise. One inconsistency is that a block
may be claimed by two inodes. Such an inconsistency can
occur when the system is halted before the pointer to the
block in the old inode has been cleared in the copy of the
old inode on the disk, and after the pointer to the block in
the new inode has been written out to the copy of the new
inode on the disk. Here, there is no deterministic method
for deciding which inode should really claim the block. A
similar problem can arise with a multiply claimed inode.
The problem with asynchronous inode updates can be
avoided by doing all inode deallocations synchronously. Con-
sequently, inodes and indirect blocks are written to the
disk synchronously (i.e. the process blocks until the infor-
mation is really written to disk) when they are being deal-
located. Similarly, inodes are kept consistent by synchro-
nously deleting, adding, or changing directory entries.
3. Fixing corrupted filesystems
A filesystem can become corrupted in several ways. The
most common of these ways are improper shutdown procedures
and hardware failures.
Filesystems may become corrupted during an unclean
halt. This happens when proper shutdown procedures are not
observed, physically write-protecting a mounted filesystem,
or a mounted filesystem is taken off-line.
SMM:3-8 The UNIX Filesystem Check Program
Filesystems may become further corrupted if proper
startup procedures are not observed, e.g., not checking a
filesystem for inconsistencies, and not repairing incon-
sistencies. Allowing a corrupted filesystem to be used (and,
thus, to be modified further) can be disastrous.
Any piece of hardware can fail at any time. Failures
can be as subtle as a bad block on a disk pack, or as bla-
tant as a non-functional disk-controller.
3.1. Detecting and correcting corruption
Normally fsck_ffs is run non-interactively. In this
mode it will only fix corruptions that are expected to occur
from an unclean halt. These actions are a proper subset of
the actions that fsck_ffs will take when it is running
interactively. Throughout this paper we assume that fsck_ffs
is being run interactively, and all possible errors can be
encountered. When an inconsistency is discovered in this
mode, fsck_ffs reports the inconsistency for the operator to
chose a corrective action.
A quiescent= filesystem may be checked for structural
integrity by performing consistency checks on the
redundant data intrinsic to a filesystem. The redundant
data is either read from the filesystem, or computed
from other known values. The filesystem must be in a
quiescent state when fsck_ffs is run, since fsck_ffs is
a multi-pass program.
In the following sections, we discuss methods to dis-
cover inconsistencies and possible corrective actions for
the cylinder group blocks, the inodes, the indirect blocks,
and the data blocks containing directory entries.
3.2. Super-block checking
The most commonly corrupted item in a filesystem is the
summary information associated with the super-block. The
summary information is prone to corruption because it is
modified with every change to the filesystem's blocks or
inodes, and is usually corrupted after an unclean halt.
The super-block is checked for inconsistencies involv-
ing filesystem size, number of inodes, free-block count, and
the free-inode count. The filesystem size must be larger
than the number of blocks used by the super-block and the
number of blocks used by the list of inodes. The filesystem
size and layout information are the most critical pieces of
information for fsck_ffs. While there is no way to actually
check these sizes, since they are statically determined by
_________________________
= I.e., unmounted and not being written on.
The UNIX Filesystem Check Program SMM:3-9
newfs, fsck_ffs can check that these sizes are within rea-
sonable bounds. All other filesystem checks require that
these sizes be correct. If fsck_ffs detects corruption in
the static parameters of the default super-block, fsck_ffs
requests the operator to specify the location of an alter-
nate super-block.
3.3. Free block checking
Fsck_ffs checks that all the blocks marked as free in
the cylinder group block maps are not claimed by any files.
When all the blocks have been initially accounted for,
fsck_ffs checks that the number of free blocks plus the
number of blocks claimed by the inodes equals the total
number of blocks in the filesystem.
If anything is wrong with the block allocation maps,
fsck_ffs will rebuild them, based on the list it has com-
puted of allocated blocks.
The summary information associated with the super-block
counts the total number of free blocks within the filesys-
tem. Fsck_ffs compares this count to the number of free
blocks it found within the filesystem. If the two counts do
not agree, then fsck_ffs replaces the incorrect count in the
summary information by the actual free-block count.
The summary information counts the total number of free
inodes within the filesystem. Fsck_ffs compares this count
to the number of free inodes it found within the filesystem.
If the two counts do not agree, then fsck_ffs replaces the
incorrect count in the summary information by the actual
free-inode count.
3.4. Checking the inode state
An individual inode is not as likely to be corrupted as
the allocation information. However, because of the great
number of active inodes, a few of the inodes are usually
corrupted.
The list of inodes in the filesystem is checked sequen-
tially starting with inode 2 (inode 0 marks unused inodes;
inode 1 is saved for future generations) and progressing
through the last inode in the filesystem. The state of each
inode is checked for inconsistencies involving format and
type, link count, duplicate blocks, bad blocks, and inode
size.
Each inode contains a mode word. This mode word
describes the type and state of the inode. Inodes must be
one of six types: regular inode, directory inode, symbolic
link inode, special block inode, special character inode, or
socket inode. Inodes may be found in one of three allocation
SMM:3-10 The UNIX Filesystem Check Program
states: unallocated, allocated, and neither unallocated nor
allocated. This last state suggests an incorrectly formated
inode. An inode can get in this state if bad data is written
into the inode list. The only possible corrective action is
for fsck_ffs is to clear the inode.
3.5. Inode links
Each inode counts the total number of directory entries
linked to the inode. Fsck_ffs verifies the link count of
each inode by starting at the root of the filesystem, and
descending through the directory structure. The actual link
count for each inode is calculated during the descent.
If the stored link count is non-zero and the actual
link count is zero, then no directory entry appears for the
inode. If this happens, fsck_ffs will place the disconnected
file in the lost+found directory. If the stored and actual
link counts are non-zero and unequal, a directory entry may
have been added or removed without the inode being updated.
If this happens, fsck_ffs replaces the incorrect stored link
count by the actual link count.
Each inode contains a list, or pointers to lists
(indirect blocks), of all the blocks claimed by the inode.
Since indirect blocks are owned by an inode, inconsistencies
in indirect blocks directly affect the inode that owns it.
Fsck_ffs compares each block number claimed by an inode
against a list of already allocated blocks. If another inode
already claims a block number, then the block number is
added to a list of duplicate blocks. Otherwise, the list of
allocated blocks is updated to include the block number.
If there are any duplicate blocks, fsck_ffs will per-
form a partial second pass over the inode list to find the
inode of the duplicated block. The second pass is needed,
since without examining the files associated with these
inodes for correct content, not enough information is avail-
able to determine which inode is corrupted and should be
cleared. If this condition does arise (only hardware failure
will cause it), then the inode with the earliest modify time
is usually incorrect, and should be cleared. If this hap-
pens, fsck_ffs prompts the operator to clear both inodes.
The operator must decide which one should be kept and which
one should be cleared.
Fsck_ffs checks the range of each block number claimed
by an inode. If the block number is lower than the first
data block in the filesystem, or greater than the last data
block, then the block number is a bad block number. Many bad
blocks in an inode are usually caused by an indirect block
that was not written to the filesystem, a condition which
can only occur if there has been a hardware failure. If an
The UNIX Filesystem Check Program SMM:3-11
inode contains bad block numbers, fsck_ffs prompts the
operator to clear it.
3.6. Inode data size
Each inode contains a count of the number of data
blocks that it contains. The number of actual data blocks is
the sum of the allocated data blocks and the indirect
blocks. Fsck_ffs computes the actual number of data blocks
and compares that block count against the actual number of
blocks the inode claims. If an inode contains an incorrect
count fsck_ffs prompts the operator to fix it.
Each inode contains a thirty-two bit size field. The
size is the number of data bytes in the file associated with
the inode. The consistency of the byte size field is roughly
checked by computing from the size field the maximum number
of blocks that should be associated with the inode, and com-
paring that expected block count against the actual number
of blocks the inode claims.
3.7. Checking the data associated with an inode
An inode can directly or indirectly reference three
kinds of data blocks. All referenced blocks must be the same
kind. The three types of data blocks are: plain data blocks,
symbolic link data blocks, and directory data blocks. Plain
data blocks contain the information stored in a file; sym-
bolic link data blocks contain the path name stored in a
link. Directory data blocks contain directory entries.
Fsck_ffs can only check the validity of directory data
blocks.
Each directory data block is checked for several types
of inconsistencies. These inconsistencies include directory
inode numbers pointing to unallocated inodes, directory
inode numbers that are greater than the number of inodes in
the filesystem, incorrect directory inode numbers for ``.''
and ``..'', and directories that are not attached to the
filesystem. If the inode number in a directory data block
references an unallocated inode, then fsck_ffs will remove
that directory entry. Again, this condition can only arise
when there has been a hardware failure.
Fsck also checks for directories with unallocated
blocks (holes). Such directories should never be created.
When found, fsck will prompt the user to adjust the length
of the offending directory which is done by shortening the
size of the directory to the end of the last allocated block
preceding the hole. Unfortunately, this means that another
Phase 1 run has to be done. Fsck will remind the user to
rerun fsck after repairing a directory containing an unallo-
cated block.
SMM:3-12 The UNIX Filesystem Check Program
If a directory entry inode number references outside
the inode list, then fsck_ffs will remove that directory
entry. This condition occurs if bad data is written into a
directory data block.
The directory inode number entry for ``.'' must be the
first entry in the directory data block. The inode number
for ``.'' must reference itself; e.g., it must equal the
inode number for the directory data block. The directory
inode number entry for ``..'' must be the second entry in
the directory data block. Its value must equal the inode
number for the parent of the directory entry (or the inode
number of the directory data block if the directory is the
root directory). If the directory inode numbers are
incorrect, fsck_ffs will replace them with the correct
values. If there are multiple hard links to a directory, the
first one encountered is considered the real parent to which
``..'' should point; fsck_ffs recommends deletion for the
subsequently discovered names.
3.8. Filesystem connectivity
Fsck_ffs checks the general connectivity of the
filesystem. If directories are not linked into the filesys-
tem, then fsck_ffs links the directory back into the
filesystem in the lost+found directory. This condition only
occurs when there has been a hardware failure.
Acknowledgements
I thank Bill Joy, Sam Leffler, Robert Elz and Dennis
Ritchie for their suggestions and help in implementing the
new filesystem. Thanks also to Robert Henry for his edi-
torial input to get this document together. Finally we thank
our sponsors, the National Science Foundation under grant
MCS80-05144, and the Defense Advance Research Projects
Agency (DoD) under Arpa Order No. 4031 monitored by Naval
Electronic System Command under Contract No. N00039-82-C-
0235. (Kirk McKusick, July 1983)
I would like to thank Larry A. Wehr for advice that
lead to the first version of fsck_ffs and Rick B. Brandt for
adapting fsck_ffs to UNIX/TS. (T. Kowalski, July 1979)
References
[Dolotta78] Dolotta, T. A., and Olsson, S. B. eds.,
UNIX User's Manual, Edition 1.1, January
1978.
[Joy83] Joy, W., Cooper, E., Fabry, R., Leffler,
The UNIX Filesystem Check Program SMM:3-13
S., McKusick, M., and Mosher, D. 4.2BSD
System Manual, University of California
at Berkeley, Computer Systems Research
Group Technical Report #4, 1982.
[McKusick84] McKusick, M., Joy, W., Leffler, S., and
Fabry, R. A Fast Filesystem for UNIX,
ACM Transactions on Computer Systems 2,
3. pp. 181-197, August 1984.
[Ritchie78] Ritchie, D. M., and Thompson, K., The
UNIX Time-Sharing System, The Bell Sys-
tem Technical Journal 57, 6 (July-August
1978, Part 2), pp. 1905-29.
[Thompson78] Thompson, K., UNIX Implementation, The
Bell System Technical Journal 57, 6
(July-August 1978, Part 2), pp. 1931-46.
SMM:3-14 The UNIX Filesystem Check Program
4. Appendix A - Fsck_ffs Error Conditions
4.1. Conventions
Fsck_ffs is a multi-pass filesystem check program. Each
filesystem pass invokes a different Phase of the fsck_ffs
program. After the initial setup, fsck_ffs performs succes-
sive Phases over each filesystem, checking blocks and sizes,
path-names, connectivity, reference counts, and the map of
free blocks, (possibly rebuilding it), and performs some
cleanup.
Normally fsck_ffs is run non-interactively to preen the
filesystems after an unclean halt. While preen'ing a
filesystem, it will only fix corruptions that are expected
to occur from an unclean halt. These actions are a proper
subset of the actions that fsck_ffs will take when it is
running interactively. Throughout this appendix many errors
have several options that the operator can take. When an
inconsistency is detected, fsck_ffs reports the error condi-
tion to the operator. If a response is required, fsck_ffs
prints a prompt message and waits for a response. When
preen'ing most errors are fatal. For those that are
expected, the response taken is noted. This appendix
explains the meaning of each error condition, the possible
responses, and the related error conditions.
The error conditions are organized by the Phase of the
fsck_ffs program in which they can occur. The error condi-
tions that may occur in more than one Phase will be dis-
cussed in initialization.
4.2. Initialization
Before a filesystem check can be performed, certain
tables have to be set up and certain files opened. This sec-
tion concerns itself with the opening of files and the ini-
tialization of tables. This section lists error conditions
resulting from command line options, memory requests, open-
ing of files, status of files, filesystem size checks, and
creation of the scratch file. All the initialization errors
are fatal when the filesystem is being preen'ed.
C option?
C is not a legal option to fsck_ffs; legal options are -b,
-c, -y, -n, and -p. Fsck_ffs terminates on this error condi-
tion. See the fsck_ffs(8) manual entry for further detail.
cannot alloc NNN bytes for blockmap
cannot alloc NNN bytes for freemap
cannot alloc NNN bytes for statemap
cannot alloc NNN bytes for lncntp
The UNIX Filesystem Check Program SMM:3-15
Fsck_ffs's request for memory for its virtual memory tables
failed. This should never happen. Fsck_ffs terminates on
this error condition. See a guru.
Can't open checklist file: F
The filesystem checklist file F (usually /etc/fstab) can not
be opened for reading. Fsck_ffs terminates on this error
condition. Check access modes of F.
Can't stat root
Fsck_ffs's request for statistics about the root directory
``/'' failed. This should never happen. Fsck_ffs terminates
on this error condition. See a guru.
Can't stat F
Can't make sense out of name F
Fsck_ffs's request for statistics about the filesystem F
failed. When running manually, it ignores this filesystem
and continues checking the next filesystem given. Check
access modes of F.
Can't open F
Fsck_ffs's request attempt to open the filesystem F failed.
When running manually, it ignores this filesystem and con-
tinues checking the next filesystem given. Check access
modes of F.
F: (NO WRITE)
Either the -n flag was specified or fsck_ffs's attempt to
open the filesystem F for writing failed. When running manu-
ally, all the diagnostics are printed out, but no modifica-
tions are attempted to fix them.
file is not a block or character device; OK
You have given fsck_ffs a regular file name by mistake.
Check the type of the file specified.
Possible responses to the OK prompt are:
YES ignore this error condition.
NO ignore this filesystem and continues checking the next
filesystem given.
UNDEFINED OPTIMIZATION IN SUPERBLOCK (SET TO DEFAULT)
The superblock optimization parameter is neither OPT_TIME
nor OPT_SPACE.
SMM:3-16 The UNIX Filesystem Check Program
Possible responses to the SET TO DEFAULT prompt are:
YES The superblock is set to request optimization to minim-
ize running time of the system. (If optimization to
minimize disk space utilization is desired, it can be
set using tunefs(8).)
NO ignore this error condition.
IMPOSSIBLE MINFREE=D IN SUPERBLOCK (SET TO DEFAULT)
The superblock minimum space percentage is greater than 99%
or less than 0%.
Possible responses to the SET TO DEFAULT prompt are:
YES The minfree parameter is set to 10%. (If some other
percentage is desired, it can be set using tunefs(8).)
NO ignore this error condition.
IMPOSSIBLE INTERLEAVE=D IN SUPERBLOCK (SET TO DEFAULT)
The filesystem interleave is less than or equal to zero.
Possible responses to the SET TO DEFAULT prompt are:
YES The interleave parameter is set to 1.
NO ignore this error condition.
IMPOSSIBLE NPSECT=D IN SUPERBLOCK (SET TO DEFAULT)
The number of physical sectors per track is less than the
number of usable sectors per track.
Possible responses to the SET TO DEFAULT prompt are:
YES The npsect parameter is set to the number of usable
sectors per track.
NO ignore this error condition.
One of the following messages will appear:
MAGIC NUMBER WRONG
NCG OUT OF RANGE
CPG OUT OF RANGE
NCYL DOES NOT JIVE WITH NCG*CPG
SIZE PREPOSTEROUSLY LARGE
TRASHED VALUES IN SUPER BLOCK
and will be followed by the message:
F: BAD SUPER BLOCK: B
USE -b OPTION TO FSCK_FFS TO SPECIFY LOCATION OF AN
The UNIX Filesystem Check Program SMM:3-17
ALTERNATE
SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; SEE fsck_ffs(8).
The super block has been corrupted. An alternative super
block must be selected from among those listed by newfs (8)
when the filesystem was created. For filesystems with a
blocksize less than 32K, specifying -b 32 is a good first
choice.
INTERNAL INCONSISTENCY: M
Fsck_ffs's has had an internal panic, whose message is
specified as M. This should never happen. See a guru.
CAN NOT SEEK: BLK B (CONTINUE)
Fsck_ffs's request for moving to a specified block number B
in the filesystem failed. This should never happen. See a
guru.
Possible responses to the CONTINUE prompt are:
YES attempt to continue to run the filesystem check. Often,
however the problem will persist. This error condition
will not allow a complete check of the filesystem. A
second run of fsck_ffs should be made to re-check this
filesystem. If the block was part of the virtual memory
buffer cache, fsck_ffs will terminate with the message
``Fatal I/O error''.
NO terminate the program.
CAN NOT READ: BLK B (CONTINUE)
Fsck_ffs's request for reading a specified block number B in
the filesystem failed. This should never happen. See a guru.
Possible responses to the CONTINUE prompt are:
YES attempt to continue to run the filesystem check. It
will retry the read and print out the message:
THE FOLLOWING SECTORS COULD NOT BE READ: N
where N indicates the sectors that could not be read.
If fsck_ffs ever tries to write back one of the blocks
on which the read failed it will print the message:
WRITING ZERO'ED BLOCK N TO DISK
where N indicates the sector that was written with
zero's. If the disk is experiencing hardware problems,
the problem will persist. This error condition will not
allow a complete check of the filesystem. A second run
of fsck_ffs should be made to re-check this filesystem.
If the block was part of the virtual memory buffer
cache, fsck_ffs will terminate with the message ``Fatal
I/O error''.
SMM:3-18 The UNIX Filesystem Check Program
NO terminate the program.
CAN NOT WRITE: BLK B (CONTINUE)
Fsck_ffs's request for writing a specified block number B in
the filesystem failed. The disk is write-protected; check
the write protect lock on the drive. If that is not the
problem, see a guru.
Possible responses to the CONTINUE prompt are:
YES attempt to continue to run the filesystem check. The
write operation will be retried with the failed blocks
indicated by the message:
THE FOLLOWING SECTORS COULD NOT BE WRITTEN: N
where N indicates the sectors that could not be writ-
ten. If the disk is experiencing hardware problems, the
problem will persist. This error condition will not
allow a complete check of the filesystem. A second run
of fsck_ffs should be made to re-check this filesystem.
If the block was part of the virtual memory buffer
cache, fsck_ffs will terminate with the message ``Fatal
I/O error''.
NO terminate the program.
bad inode number DDD to ginode
An internal error has attempted to read non-existent inode
DDD. This error causes fsck_ffs to exit. See a guru.
4.3. Phase 1 - Check Blocks and Sizes
This phase concerns itself with the inode list. This
section lists error conditions resulting from checking inode
types, setting up the zero-link-count table, examining inode
block numbers for bad or duplicate blocks, checking inode
size, and checking inode format. All errors in this phase
except INCORRECT BLOCK COUNT and PARTIALLY TRUNCATED INODE
are fatal if the filesystem is being preen'ed.
UNKNOWN FILE TYPE I=I (CLEAR)
The mode word of the inode I indicates that the inode is not
a special block inode, special character inode, socket
inode, regular inode, symbolic link, or directory inode.
Possible responses to the CLEAR prompt are:
YES de-allocate inode I by zeroing its contents. This will
always invoke the UNALLOCATED error condition in Phase
2 for each directory entry pointing to this inode.
NO ignore this error condition.
The UNIX Filesystem Check Program SMM:3-19
PARTIALLY TRUNCATED INODE I=I (SALVAGE)
Fsck_ffs has found inode I whose size is shorter than the
number of blocks allocated to it. This condition should only
occur if the system crashes while in the midst of truncating
a file. When preen'ing the filesystem, fsck_ffs completes
the truncation to the specified size.
Possible responses to SALVAGE are:
YES complete the truncation to the size specified in the
inode.
NO ignore this error condition.
LINK COUNT TABLE OVERFLOW (CONTINUE)
An internal table for fsck_ffs containing allocated inodes
with a link count of zero cannot allocate more memory.
Increase the virtual memory for fsck_ffs.
Possible responses to the CONTINUE prompt are:
YES continue with the program. This error condition will
not allow a complete check of the filesystem. A second
run of fsck_ffs should be made to re-check this
filesystem. If another allocated inode with a zero link
count is found, this error condition is repeated.
NO terminate the program.
B BAD I=I
Inode I contains block number B with a number lower than the
number of the first data block in the filesystem or greater
than the number of the last block in the filesystem. This
error condition may invoke the EXCESSIVE BAD BLKS error con-
dition in Phase 1 (see next paragraph) if inode I has too
many block numbers outside the filesystem range. This error
condition will always invoke the BAD/DUP error condition in
Phase 2 and Phase 4.
EXCESSIVE BAD BLKS I=I (CONTINUE)
There is more than a tolerable number (usually 10) of blocks
with a number lower than the number of the first data block
in the filesystem or greater than the number of last block
in the filesystem associated with inode I.
Possible responses to the CONTINUE prompt are:
YES ignore the rest of the blocks in this inode and con-
tinue checking with the next inode in the filesystem.
This error condition will not allow a complete check of
the filesystem. A second run of fsck_ffs should be made
SMM:3-20 The UNIX Filesystem Check Program
to re-check this filesystem.
NO terminate the program.
BAD STATE DDD TO BLKERR
An internal error has scrambled fsck_ffs's state map to have
the impossible value DDD. Fsck_ffs exits immediately. See a
guru.
B DUP I=I
Inode I contains block number B that is already claimed by
another inode. This error condition may invoke the EXCESSIVE
DUP BLKS error condition in Phase 1 if inode I has too many
block numbers claimed by other inodes. This error condition
will always invoke Phase 1b and the BAD/DUP error condition
in Phase 2 and Phase 4.
EXCESSIVE DUP BLKS I=I (CONTINUE)
There is more than a tolerable number (usually 10) of blocks
claimed by other inodes.
Possible responses to the CONTINUE prompt are:
YES ignore the rest of the blocks in this inode and con-
tinue checking with the next inode in the filesystem.
This error condition will not allow a complete check of
the filesystem. A second run of fsck_ffs should be made
to re-check this filesystem.
NO terminate the program.
DUP TABLE OVERFLOW (CONTINUE)
An internal table in fsck_ffs containing duplicate block
numbers cannot allocate any more space. Increase the amount
of virtual memory available to fsck_ffs.
Possible responses to the CONTINUE prompt are:
YES continue with the program. This error condition will
not allow a complete check of the filesystem. A second
run of fsck_ffs should be made to re-check this
filesystem. If another duplicate block is found, this
error condition will repeat.
NO terminate the program.
PARTIALLY ALLOCATED INODE I=I (CLEAR)
Inode I is neither allocated nor unallocated.
The UNIX Filesystem Check Program SMM:3-21
Possible responses to the CLEAR prompt are:
YES de-allocate inode I by zeroing its contents.
NO ignore this error condition.
INCORRECT BLOCK COUNT I=I (X should be Y) (CORRECT)
The block count for inode I is X blocks, but should be Y
blocks. When preen'ing the count is corrected.
Possible responses to the CORRECT prompt are:
YES replace the block count of inode I with Y.
NO ignore this error condition.
4.4. Phase 1B: Rescan for More Dups
When a duplicate block is found in the filesystem, the
filesystem is rescanned to find the inode that previously
claimed that block. This section lists the error condition
when the duplicate block is found.
B DUP I=I
Inode I contains block number B that is already claimed by
another inode. This error condition will always invoke the
BAD/DUP error condition in Phase 2. You can determine which
inodes have overlapping blocks by examining this error con-
dition and the DUP error condition in Phase 1.
4.5. Phase 2 - Check Pathnames
This phase concerns itself with removing directory
entries pointing to error conditioned inodes from Phase 1
and Phase 1b. This section lists error conditions resulting
from root inode mode and status, directory inode pointers in
range, and directory entries pointing to bad inodes, and
directory integrity checks. All errors in this phase are
fatal if the filesystem is being preen'ed, except for direc-
tories not being a multiple of the blocks size and extrane-
ous hard links.
ROOT INODE UNALLOCATED (ALLOCATE)
The root inode (usually inode number 2) has no allocate mode
bits. This should never happen.
Possible responses to the ALLOCATE prompt are:
YES allocate inode 2 as the root inode. The files and
directories usually found in the root will be recovered
in Phase 3 and put into lost+found. If the attempt to
SMM:3-22 The UNIX Filesystem Check Program
allocate the root fails, fsck_ffs will exit with the
message:
CANNOT ALLOCATE ROOT INODE.
NO fsck_ffs will exit.
ROOT INODE NOT DIRECTORY (REALLOCATE)
The root inode (usually inode number 2) is not directory
inode type.
Possible responses to the REALLOCATE prompt are:
YES clear the existing contents of the root inode and real-
locate it. The files and directories usually found in
the root will be recovered in Phase 3 and put into
lost+found. If the attempt to allocate the root fails,
fsck_ffs will exit with the message:
CANNOT ALLOCATE ROOT INODE.
NO fsck_ffs will then prompt with FIX
Possible responses to the FIX prompt are:
YES replace the root inode's type to be a directory. If the
root inode's data blocks are not directory blocks, many
error conditions will be produced.
NO terminate the program.
DUPS/BAD IN ROOT INODE (REALLOCATE)
Phase 1 or Phase 1b have found duplicate blocks or bad
blocks in the root inode (usually inode number 2) for the
filesystem.
Possible responses to the REALLOCATE prompt are:
YES clear the existing contents of the root inode and real-
locate it. The files and directories usually found in
the root will be recovered in Phase 3 and put into
lost+found. If the attempt to allocate the root fails,
fsck_ffs will exit with the message:
CANNOT ALLOCATE ROOT INODE.
NO fsck_ffs will then prompt with CONTINUE.
Possible responses to the CONTINUE prompt are:
YES ignore the DUPS/BAD error condition in the root inode
and attempt to continue to run the filesystem check. If
the root inode is not correct, then this may result in
many other error conditions.
The UNIX Filesystem Check Program SMM:3-23
NO terminate the program.
NAME TOO LONG F
An excessively long path name has been found. This usually
indicates loops in the filesystem name space. This can occur
if the super user has made circular links to directories.
The offending links must be removed (by a guru).
I OUT OF RANGE I=I NAME=F (REMOVE)
A directory entry F has an inode number I that is greater
than the end of the inode list.
Possible responses to the REMOVE prompt are:
YES the directory entry F is removed.
NO ignore this error condition.
UNALLOCATED I=I OWNER=O MODE=M SIZE=S MTIME=T type=F
(REMOVE)
A directory or file entry F points to an unallocated inode
I. The owner O, mode M, size S, modify time T, and name F
are printed.
Possible responses to the REMOVE prompt are:
YES the directory entry F is removed.
NO ignore this error condition.
DUP/BAD I=I OWNER=O MODE=M SIZE=S MTIME=T type=F (REMOVE)
Phase 1 or Phase 1b have found duplicate blocks or bad
blocks associated with directory or file entry F, inode I.
The owner O, mode M, size S, modify time T, and directory
name F are printed.
Possible responses to the REMOVE prompt are:
YES the directory entry F is removed.
NO ignore this error condition.
ZERO LENGTH DIRECTORY I=I OWNER=O MODE=M SIZE=S MTIME=T
DIR=F (REMOVE)
A directory entry F has a size S that is zero. The owner O,
mode M, size S, modify time T, and directory name F are
printed.
Possible responses to the REMOVE prompt are:
SMM:3-24 The UNIX Filesystem Check Program
YES the directory entry F is removed; this will always
invoke the BAD/DUP error condition in Phase 4.
NO ignore this error condition.
DIRECTORY TOO SHORT I=I OWNER=O MODE=M SIZE=S MTIME=T DIR=F
(FIX)
A directory F has been found whose size S is less than the
minimum size directory. The owner O, mode M, size S, modify
time T, and directory name F are printed.
Possible responses to the FIX prompt are:
YES increase the size of the directory to the minimum
directory size.
NO ignore this directory.
DIRECTORY F LENGTH S NOT MULTIPLE OF B (ADJUST)
A directory F has been found with size S that is not a mul-
tiple of the directory blocksize B.
Possible responses to the ADJUST prompt are:
YES the length is rounded up to the appropriate block size.
This error can occur on 4.2BSD filesystems. Thus when
preen'ing the filesystem only a warning is printed and
the directory is adjusted.
NO ignore the error condition.
DIRECTORY CORRUPTED I=I OWNER=O MODE=M SIZE=S MTIME=T DIR=F
(SALVAGE)
A directory with an inconsistent internal state has been
found.
Possible responses to the FIX prompt are:
YES throw away all entries up to the next directory boun-
dary (usually 512-byte) boundary. This drastic action
can throw away up to 42 entries, and should be taken
only after other recovery efforts have failed.
NO skip up to the next directory boundary and resume read-
ing, but do not modify the directory.
BAD INODE NUMBER FOR `.' I=I OWNER=O MODE=M SIZE=S MTIME=T
DIR=F (FIX)
A directory I has been found whose inode number for `.' does
does not equal I.
The UNIX Filesystem Check Program SMM:3-25
Possible responses to the FIX prompt are:
YES change the inode number for `.' to be equal to I.
NO leave the inode number for `.' unchanged.
MISSING `.' I=I OWNER=O MODE=M SIZE=S MTIME=T DIR=F (FIX)
A directory I has been found whose first entry is unallo-
cated.
Possible responses to the FIX prompt are:
YES build an entry for `.' with inode number equal to I.
NO leave the directory unchanged.
MISSING `.' I=I OWNER=O MODE=M SIZE=S MTIME=T DIR=F
CANNOT FIX, FIRST ENTRY IN DIRECTORY CONTAINS F
A directory I has been found whose first entry is F.
Fsck_ffs cannot resolve this problem. The filesystem should
be mounted and the offending entry F moved elsewhere. The
filesystem should then be unmounted and fsck_ffs should be
run again.
MISSING `.' I=I OWNER=O MODE=M SIZE=S MTIME=T DIR=F
CANNOT FIX, INSUFFICIENT SPACE TO ADD `.'
A directory I has been found whose first entry is not `.'.
Fsck_ffs cannot resolve this problem as it should never hap-
pen. See a guru.
EXTRA `.' ENTRY I=I OWNER=O MODE=M SIZE=S MTIME=T DIR=F
(FIX)
A directory I has been found that has more than one entry
for `.'.
Possible responses to the FIX prompt are:
YES remove the extra entry for `.'.
NO leave the directory unchanged.
BAD INODE NUMBER FOR `..' I=I OWNER=O MODE=M SIZE=S MTIME=T
DIR=F (FIX)
A directory I has been found whose inode number for `..'
does does not equal the parent of I.
Possible responses to the FIX prompt are:
YES change the inode number for `..' to be equal to the
SMM:3-26 The UNIX Filesystem Check Program
parent of I (``..'' in the root inode points to
itself).
NO leave the inode number for `..' unchanged.
MISSING `..' I=I OWNER=O MODE=M SIZE=S MTIME=T DIR=F (FIX)
A directory I has been found whose second entry is unallo-
cated.
Possible responses to the FIX prompt are:
YES build an entry for `..' with inode number equal to the
parent of I (``..'' in the root inode points to
itself).
NO leave the directory unchanged.
MISSING `..' I=I OWNER=O MODE=M SIZE=S MTIME=T DIR=F
CANNOT FIX, SECOND ENTRY IN DIRECTORY CONTAINS F
A directory I has been found whose second entry is F.
Fsck_ffs cannot resolve this problem. The filesystem should
be mounted and the offending entry F moved elsewhere. The
filesystem should then be unmounted and fsck_ffs should be
run again.
MISSING `..' I=I OWNER=O MODE=M SIZE=S MTIME=T DIR=F
CANNOT FIX, INSUFFICIENT SPACE TO ADD `..'
A directory I has been found whose second entry is not `..'.
Fsck_ffs cannot resolve this problem. The filesystem should
be mounted and the second entry in the directory moved else-
where. The filesystem should then be unmounted and fsck_ffs
should be run again.
EXTRA `..' ENTRY I=I OWNER=O MODE=M SIZE=S MTIME=T DIR=F
(FIX)
A directory I has been found that has more than one entry
for `..'.
Possible responses to the FIX prompt are:
YES remove the extra entry for `..'.
NO leave the directory unchanged.
N IS AN EXTRANEOUS HARD LINK TO A DIRECTORY D (REMOVE)
Fsck_ffs has found a hard link, N, to a directory, D. When
preen'ing the extraneous links are ignored.
Possible responses to the REMOVE prompt are:
The UNIX Filesystem Check Program SMM:3-27
YES delete the extraneous entry, N.
NO ignore the error condition.
BAD INODE S TO DESCEND
An internal error has caused an impossible state S to be
passed to the routine that descends the filesystem directory
structure. Fsck_ffs exits. See a guru.
BAD RETURN STATE S FROM DESCEND
An internal error has caused an impossible state S to be
returned from the routine that descends the filesystem
directory structure. Fsck_ffs exits. See a guru.
BAD STATE S FOR ROOT INODE
An internal error has caused an impossible state S to be
assigned to the root inode. Fsck_ffs exits. See a guru.
4.6. Phase 3 - Check Connectivity
This phase concerns itself with the directory connec-
tivity seen in Phase 2. This section lists error conditions
resulting from unreferenced directories, and missing or full
lost+found directories.
UNREF DIR I=I OWNER=O MODE=M SIZE=S MTIME=T (RECONNECT)
The directory inode I was not connected to a directory entry
when the filesystem was traversed. The owner O, mode M, size
S, and modify time T of directory inode I are printed. When
preen'ing, the directory is reconnected if its size is non-
zero, otherwise it is cleared.
Possible responses to the RECONNECT prompt are:
YES reconnect directory inode I to the filesystem in the
directory for lost files (usually lost+found). This may
invoke the lost+found error condition in Phase 3 if
there are problems connecting directory inode I to
lost+found. This may also invoke the CONNECTED error
condition in Phase 3 if the link was successful.
NO ignore this error condition. This will always invoke
the UNREF error condition in Phase 4.
NO lost+found DIRECTORY (CREATE)
There is no lost+found directory in the root directory of
the filesystem; When preen'ing fsck_ffs tries to create a
lost+found directory.
SMM:3-28 The UNIX Filesystem Check Program
Possible responses to the CREATE prompt are:
YES create a lost+found directory in the root of the
filesystem. This may raise the message:
NO SPACE LEFT IN / (EXPAND)
See below for the possible responses. Inability to
create a lost+found directory generates the message:
SORRY. CANNOT CREATE lost+found DIRECTORY
and aborts the attempt to linkup the lost inode. This
will always invoke the UNREF error condition in Phase
4.
NO abort the attempt to linkup the lost inode. This will
always invoke the UNREF error condition in Phase 4.
lost+found IS NOT A DIRECTORY (REALLOCATE)
The entry for lost+found is not a directory.
Possible responses to the REALLOCATE prompt are:
YES allocate a directory inode, and change lost+found to
reference it. The previous inode reference by the
lost+found name is not cleared. Thus it will either be
reclaimed as an UNREF'ed inode or have its link count
ADJUST'ed later in this Phase. Inability to create a
lost+found directory generates the message:
SORRY. CANNOT CREATE lost+found DIRECTORY
and aborts the attempt to linkup the lost inode. This
will always invoke the UNREF error condition in Phase
4.
NO abort the attempt to linkup the lost inode. This will
always invoke the UNREF error condition in Phase 4.
NO SPACE LEFT IN /lost+found (EXPAND)
There is no space to add another entry to the lost+found
directory in the root directory of the filesystem. When
preen'ing the lost+found directory is expanded.
Possible responses to the EXPAND prompt are:
YES the lost+found directory is expanded to make room for
the new entry. If the attempted expansion fails
fsck_ffs prints the message:
SORRY. NO SPACE IN lost+found DIRECTORY
and aborts the attempt to linkup the lost inode. This
will always invoke the UNREF error condition in Phase
4. Clean out unnecessary entries in lost+found. This
error is fatal if the filesystem is being preen'ed.
NO abort the attempt to linkup the lost inode. This will
always invoke the UNREF error condition in Phase 4.
The UNIX Filesystem Check Program SMM:3-29
DIR I=I1 CONNECTED. PARENT WAS I=I2
This is an advisory message indicating a directory inode I1
was successfully connected to the lost+found directory. The
parent inode I2 of the directory inode I1 is replaced by the
inode number of the lost+found directory.
DIRECTORY F LENGTH S NOT MULTIPLE OF B (ADJUST)
A directory F has been found with size S that is not a mul-
tiple of the directory blocksize B (this can reoccur in
Phase 3 if it is not adjusted in Phase 2).
Possible responses to the ADJUST prompt are:
YES the length is rounded up to the appropriate block size.
This error can occur on 4.2BSD filesystems. Thus when
preen'ing the filesystem only a warning is printed and
the directory is adjusted.
NO ignore the error condition.
BAD INODE S TO DESCEND
An internal error has caused an impossible state S to be
passed to the routine that descends the filesystem directory
structure. Fsck_ffs exits. See a guru.
4.7. Phase 4 - Check Reference Counts
This phase concerns itself with the link count informa-
tion seen in Phase 2 and Phase 3. This section lists error
conditions resulting from unreferenced files, missing or
full lost+found directory, incorrect link counts for files,
directories, symbolic links, or special files, unreferenced
files, symbolic links, and directories, and bad or duplicate
blocks in files, symbolic links, and directories. All errors
in this phase are correctable if the filesystem is being
preen'ed except running out of space in the lost+found
directory.
UNREF FILE I=I OWNER=O MODE=M SIZE=S MTIME=T (RECONNECT)
Inode I was not connected to a directory entry when the
filesystem was traversed. The owner O, mode M, size S, and
modify time T of inode I are printed. When preen'ing the
file is cleared if either its size or its link count is
zero, otherwise it is reconnected.
Possible responses to the RECONNECT prompt are:
YES reconnect inode I to the filesystem in the directory
for lost files (usually lost+found). This may invoke
the lost+found error condition in Phase 4 if there are
problems connecting inode I to lost+found.
SMM:3-30 The UNIX Filesystem Check Program
NO ignore this error condition. This will always invoke
the CLEAR error condition in Phase 4.
(CLEAR)
The inode mentioned in the immediately previous error condi-
tion can not be reconnected. This cannot occur if the
filesystem is being preen'ed, since lack of space to recon-
nect files is a fatal error.
Possible responses to the CLEAR prompt are:
YES de-allocate the inode mentioned in the immediately pre-
vious error condition by zeroing its contents.
NO ignore this error condition.
NO lost+found DIRECTORY (CREATE)
There is no lost+found directory in the root directory of
the filesystem; When preen'ing fsck_ffs tries to create a
lost+found directory.
Possible responses to the CREATE prompt are:
YES create a lost+found directory in the root of the
filesystem. This may raise the message:
NO SPACE LEFT IN / (EXPAND)
See below for the possible responses. Inability to
create a lost+found directory generates the message:
SORRY. CANNOT CREATE lost+found DIRECTORY
and aborts the attempt to linkup the lost inode. This
will always invoke the UNREF error condition in Phase
4.
NO abort the attempt to linkup the lost inode. This will
always invoke the UNREF error condition in Phase 4.
lost+found IS NOT A DIRECTORY (REALLOCATE)
The entry for lost+found is not a directory.
Possible responses to the REALLOCATE prompt are:
YES allocate a directory inode, and change lost+found to
reference it. The previous inode reference by the
lost+found name is not cleared. Thus it will either be
reclaimed as an UNREF'ed inode or have its link count
ADJUST'ed later in this Phase. Inability to create a
lost+found directory generates the message:
SORRY. CANNOT CREATE lost+found DIRECTORY
and aborts the attempt to linkup the lost inode. This
will always invoke the UNREF error condition in Phase
4.
The UNIX Filesystem Check Program SMM:3-31
NO abort the attempt to linkup the lost inode. This will
always invoke the UNREF error condition in Phase 4.
NO SPACE LEFT IN /lost+found (EXPAND)
There is no space to add another entry to the lost+found
directory in the root directory of the filesystem. When
preen'ing the lost+found directory is expanded.
Possible responses to the EXPAND prompt are:
YES the lost+found directory is expanded to make room for
the new entry. If the attempted expansion fails
fsck_ffs prints the message:
SORRY. NO SPACE IN lost+found DIRECTORY
and aborts the attempt to linkup the lost inode. This
will always invoke the UNREF error condition in Phase
4. Clean out unnecessary entries in lost+found. This
error is fatal if the filesystem is being preen'ed.
NO abort the attempt to linkup the lost inode. This will
always invoke the UNREF error condition in Phase 4.
LINK COUNT type I=I OWNER=O MODE=M SIZE=S MTIME=T COUNT=X
SHOULD BE Y (ADJUST)
The link count for inode I, is X but should be Y. The owner
O, mode M, size S, and modify time T are printed. When
preen'ing the link count is adjusted unless the number of
references is increasing, a condition that should never
occur unless precipitated by a hardware failure. When the
number of references is increasing under preen mode,
fsck_ffs exits with the message:
LINK COUNT INCREASING
Possible responses to the ADJUST prompt are:
YES replace the link count of file inode I with Y.
NO ignore this error condition.
UNREF type I=I OWNER=O MODE=M SIZE=S MTIME=T (CLEAR)
Inode I, was not connected to a directory entry when the
filesystem was traversed. The owner O, mode M, size S, and
modify time T of inode I are printed. When preen'ing, this
is a file that was not connected because its size or link
count was zero, hence it is cleared.
Possible responses to the CLEAR prompt are:
YES de-allocate inode I by zeroing its contents.
NO ignore this error condition.
SMM:3-32 The UNIX Filesystem Check Program
BAD/DUP type I=I OWNER=O MODE=M SIZE=S MTIME=T (CLEAR)
Phase 1 or Phase 1b have found duplicate blocks or bad
blocks associated with inode I. The owner O, mode M, size S,
and modify time T of inode I are printed. This error cannot
arise when the filesystem is being preen'ed, as it would
have caused a fatal error earlier.
Possible responses to the CLEAR prompt are:
YES de-allocate inode I by zeroing its contents.
NO ignore this error condition.
4.8. Phase 5 - Check Cyl groups
This phase concerns itself with the free-block and
used-inode maps. This section lists error conditions result-
ing from allocated blocks in the free-block maps, free
blocks missing from free-block maps, and the total free-
block count incorrect. It also lists error conditions
resulting from free inodes in the used-inode maps, allocated
inodes missing from used-inode maps, and the total used-
inode count incorrect.
CG C: BAD MAGIC NUMBER
The magic number of cylinder group C is wrong. This usually
indicates that the cylinder group maps have been destroyed.
When running manually the cylinder group is marked as need-
ing to be reconstructed. This error is fatal if the filesys-
tem is being preen'ed.
BLK(S) MISSING IN BIT MAPS (SALVAGE)
A cylinder group block map is missing some free blocks. Dur-
ing preen'ing the maps are reconstructed.
Possible responses to the SALVAGE prompt are:
YES reconstruct the free block map.
NO ignore this error condition.
SUMMARY INFORMATION BAD (SALVAGE)
The summary information was found to be incorrect. When
preen'ing, the summary information is recomputed.
Possible responses to the SALVAGE prompt are:
YES reconstruct the summary information.
NO ignore this error condition.
The UNIX Filesystem Check Program SMM:3-33
FREE BLK COUNT(S) WRONG IN SUPERBLOCK (SALVAGE)
The superblock free block information was found to be
incorrect. When preen'ing, the superblock free block infor-
mation is recomputed.
Possible responses to the SALVAGE prompt are:
YES reconstruct the superblock free block information.
NO ignore this error condition.
4.9. Cleanup
Once a filesystem has been checked, a few cleanup func-
tions are performed. This section lists advisory messages
about the filesystem and modify status of the filesystem.
V files, W used, X free (Y frags, Z blocks)
This is an advisory message indicating that the filesystem
checked contained V files using W fragment sized blocks
leaving X fragment sized blocks free in the filesystem. The
numbers in parenthesis breaks the free count down into Y
free fragments and Z free full sized blocks.
***** REBOOT UNIX *****
This is an advisory message indicating that the root
filesystem has been modified by fsck_ffs. If UNIX is not
rebooted immediately, the work done by fsck_ffs may be
undone by the in-core copies of tables UNIX keeps. When
preen'ing, fsck_ffs will exit with a code of 4. The standard
auto-reboot script distributed with 4.3BSD interprets an
exit code of 4 by issuing a reboot system call.
***** FILESYSTEM WAS MODIFIED *****
This is an advisory message indicating that the current
filesystem was modified by fsck_ffs. If this filesystem is
mounted or is the current root filesystem, fsck_ffs should
be halted and UNIX rebooted. If UNIX is not rebooted immedi-
ately, the work done by fsck_ffs may be undone by the in-
core copies of tables UNIX keeps.