+.th CHECK VIII 8/31/73
+.sh NAME
+check \*- file system consistency check
+.sh SYNOPSIS
+.bd check
+[
+.bd \*-lsib
+[ numbers ]
+]
+[ filesystem ]
+.sh DESCRIPTION
+.it Check
+examines a file system,
+builds a bit map of used blocks,
+and compares this bit map against
+the free list maintained on the file system.
+It also reads directories and compares
+the link-count in each i-node with the number of directory
+entries by which it is referenced.
+If the file system is not specified,
+a check of a
+default file system
+is performed.
+The normal output of
+.it check
+includes a report of
+.s3
+.lp +4 0
+The number of blocks missing; i.e. not in any file
+nor in the free list,
+.lp +4 0
+The number of special files,
+.lp +4 0
+The total number of files,
+.lp +4 0
+The number of large files,
+.lp +4 0
+The number of directories,
+.lp +4 0
+The number of indirect blocks,
+.lp +4 0
+The number of blocks used in files,
+.lp +4 0
+The highest-numbered block appearing in a file,
+.lp +4 0
+The number of free blocks.
+.s3
+.i0
+The
+.bd \*-l
+flag causes
+.it check
+to produce as part of its output report a list of the
+all the path names of files on the file system.
+The list is in i-number order; the first
+name for each file gives the i-number while subsequent
+names (i.e. links) have the i-number suppressed.
+The entries ``\fB.\fR'' and ``\fB..\fR''
+for directories are also suppressed.
+.s3
+The
+.bd \*-s
+flag causes
+.it check
+to ignore the actual free list and reconstruct a new one
+by rewriting the super-block of the file system.
+The file system should be dismounted while this is done;
+if this is not possible (for example if
+the root file system has to be salvaged)
+care should be taken that the system is quiescent and that
+it is rebooted immediately afterwards so that the old, bad in-core
+copy of the super-block will not continue to be used.
+Notice also that
+the words in the super-block
+which indicate the size of the free list and of the
+i-list are believed.
+If the super-block has been curdled
+these words will have to be patched.
+The
+.bd \*-s
+flag
+causes the normal output reports to be suppressed.
+.s3
+The occurrence
+of
+.bd i
+.it n
+times in a flag argument
+.bd \*-ii...i
+causes
+.it check
+to store away the next
+.it n
+arguments which are taken to be i-numbers.
+When any of these i-numbers is encountered in a directory
+a diagnostic is produced, as described below, which indicates among
+other things the entry name.
+.s3
+Likewise,
+.it n
+appearances of
+.bd b
+in a flag like
+.bd \*-bb...b
+cause the next
+.it n
+arguments to be taken as block numbers
+which are remembered;
+whenever any of the named blocks turns up in a file,
+a diagnostic is produced.
+.sh FILES
+Currently, /dev/rp0 is the default file system.
+.sh "SEE ALSO"
+fs (V)
+.sh DIAGNOSTICS
+There are some self-evident diagnostics like
+``can't open ...'', ``can't write ....''
+If a read error is encountered,
+the block number of the bad block is printed and
+.it check
+exits.
+``Bad freeblock'' means that
+a block number outside the available space was encountered in the free list.
+``\fIn\fR dups in free''
+means that \fIn\fR blocks were found in the free list which
+duplicate blocks either in some file or in the earlier part of the free list.
+.s3
+An important class of diagnostics is produced by a routine which
+is called for each block which is encountered in an i-node
+corresponding to an ordinary file or directory.
+These have the form
+.s3
+.dt
+ \fIb# complaint \fB; i= \fIi# \fB(\fIclass \fB)\fR
+.s3
+Here
+.it b#
+is the block number being considered;
+.it complaint
+is the diagnostic itself.
+It may be
+.s3
+.lp +8 5
+\fBblk\fR if the block number was mentioned as an argument
+after
+.bd \*-b;
+.lp +8 5
+\fBbad\fR if the block number has a value not inside the allocatable space
+on the device, as indicated by the devices's super-block;
+.lp +8 5
+\fBdup\fR if the block number has already been seen in a file;
+.lp +8 5
+\fBdin\fR if
+the block is a member of a directory, and if an entry is found
+therein whose i-number is outside the
+range of the i-list on the device, as indicated by the
+i-list size specified by the super-block.
+Unfortunately this diagnostic does not indicate the
+offending entry name, but since the i-number
+of the directory itself is given (see below)
+the problem can be tracked down.
+.s3
+.i0
+The
+.it i#
+in the form above is the i-number in which the named block was found.
+The
+.it class
+is an indicator of what type of block was involved in the
+difficulty:
+.s3
+.lp +8 5
+\fBsdir\fR indicates that the block is a data block in a small file;
+.lp +8 5
+\fBldir\fR indicates that the block is a data block in a large file
+(the indirect block number is not available);
+.lp +8 5
+\fBidir\fR indicates that the block is an indirect block
+(pointing to data blocks) in a large file;
+.lp +8 5
+\fBfree\fR indicates that the block was mentioned after
+.bd \*-b
+and is free;
+.lp +8 5
+\fBurk\fR indicates a malfunction in
+.it check.
+.s3
+.i0
+When an i-number specified after
+.bd \*-i
+is encountered while reading a directory,
+a report in the form
+.s3
+ \fi# \fBino; i= \fId# \fB(\fIclass \fB) \fIname\fR
+.s3
+where
+.it i#
+is the requested i-number.
+.it d#
+is the i-number of the directory,
+.it class
+is the class of the directory block as discussed above
+(virtually always
+``sdir'')
+and
+.it name
+is the entry name.
+This diagnostic gives enough information
+to find a full path name for an i-number
+without using the
+.bd -l
+option:
+use
+.bd \*-b
+.it n
+to find an entry name and
+the i-number of the directory containing the reference to
+.it n,
+then recursively use
+.bd \*-b
+on the i-number of the directory to find its name.
+.s3
+Another important class of
+file system diseases indicated
+by
+.it check
+is files for which the number of directory entries does
+not agree with the link-count field of the i-node.
+The diagnostic is hard to interpret.
+It has the form
+.s3
+.dt
+.ft I
+ i# delta
+.ft R
+.s3
+Here
+.it i#
+is the i-number affected.
+.it Delta
+is an octal number accumulated in a byte, and thus can have the
+value 0 through 377(8).
+The easiest way (short of rewriting the routine)
+of explaining the significance of
+.it delta
+is to describe how it is computed.
+.s3
+If the associated i-node is allocated
+(that is, has the
+.it allocated
+bit on)
+add 100 to
+.it delta.
+If its link-count is non-zero,
+add another 100 plus the link-count.
+Each time a directory entry specifying
+the associated i-number is encountered,
+subtract 1 from
+.it delta.
+At the end,
+the i-number and
+.it delta
+are printed if
+.it delta
+is neither 0 nor 200.
+The first case indicates that the i-node was unallocated
+and no entries for it appear;
+the second that it was allocated
+and that the link-count and the number of directory entries agree.
+.s3
+Therefore (to explain the symptoms of the most common difficulties)
+.it delta
+= 377 (\*-1 in 8-bit, 2's complement octal)
+means that there is a directory entry for an unallocated
+i-node.
+This is somewhat serious and the entry should be be found and removed forthwith.
+.it Delta
+= 201 usually means that a normal,
+allocated i-node has no directory entry.
+This difficulty is much less serious.
+Whatever blocks there are in the file
+are unavailable, but no further damage
+will occur if nothing is done.
+A
+.it clri
+followed by a
+.it "check \*-s"
+will restore the lost space at leisure.
+.s3
+In general,
+values of
+.it delta
+equal to or somewhat above 0, 100, or 200
+are relatively innocuous;
+just below these numbers there is danger of
+spreading infection.
+.sh BUGS
+Unfortunately,
+.it "check \*-l"
+on file systems
+with more than 3000 or so files
+does not work because it runs out of core.
+.s3
+Since
+.it check
+is inherently two-pass in nature, extraneous diagnostics
+may be produced if applied to active file systems.
+.s3
+It believes even preposterous super-blocks and
+consequently can get core images.
projects / unix-history / commitdiff