diff options
Diffstat (limited to 'sbin/fsck/SMM.doc')
| -rw-r--r-- | sbin/fsck/SMM.doc/0.t | 150 | ||||
| -rw-r--r-- | sbin/fsck/SMM.doc/1.t | 83 | ||||
| -rw-r--r-- | sbin/fsck/SMM.doc/2.t | 265 | ||||
| -rw-r--r-- | sbin/fsck/SMM.doc/3.t | 452 | ||||
| -rw-r--r-- | sbin/fsck/SMM.doc/4.t | 1424 | ||||
| -rw-r--r-- | sbin/fsck/SMM.doc/Makefile | 7 |
6 files changed, 0 insertions, 2381 deletions
diff --git a/sbin/fsck/SMM.doc/0.t b/sbin/fsck/SMM.doc/0.t deleted file mode 100644 index 528dd96..0000000 --- a/sbin/fsck/SMM.doc/0.t +++ /dev/null @@ -1,150 +0,0 @@ -.\" Copyright (c) 1986, 1993 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" -.\" @(#)0.t 8.1 (Berkeley) 6/8/93 -.\" -.if n .ND -.TL -Fsck \- The UNIX\(dg File System Check Program -.EH 'SMM:3-%''The \s-2UNIX\s+2 File System Check Program' -.OH 'The \s-2UNIX\s+2 File System Check Program''SMM:3-%' -.AU -Marshall Kirk McKusick -.AI -Computer Systems Research Group -Computer Science Division -Department of Electrical Engineering and Computer Science -University of California, Berkeley -Berkeley, CA 94720 -.AU -T. J. Kowalski -.AI -Bell Laboratories -Murray Hill, New Jersey 07974 -.AB -.FS -\(dgUNIX is a trademark of Bell Laboratories. -.FE -.FS -This work was done under grants from -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. -.FE -This document reflects the use of -.I fsck -with the 4.2BSD and 4.3BSD file system organization. This -is a revision of the -original paper written by -T. J. Kowalski. -.PP -File System Check Program (\fIfsck\fR) -is an interactive file system check and repair program. -.I Fsck -uses the redundant structural information in the -UNIX file system to perform several consistency checks. -If an inconsistency is detected, it is reported -to the operator, who may elect to fix or ignore -each inconsistency. -These inconsistencies result from the permanent interruption -of the file system updates, which are performed every -time a file is modified. -Unless there has been a hardware failure, -.I fsck -is able to repair corrupted file systems -using procedures based upon the order in which UNIX honors -these file system update requests. -.PP -The purpose of this document is to describe the normal updating -of the file system, -to discuss the possible causes of file system corruption, -and to present the corrective actions implemented -by -.I fsck. -Both the program and the interaction between the -program and the operator are described. -.sp 2 -.LP -Revised October 7, 1996 -.AE -.LP -.bp -.ce -.B "TABLE OF CONTENTS" -.LP -.sp 1 -.nf -.B "1. Introduction" -.LP -.sp .5v -.nf -.B "2. Overview of the file system -2.1. Superblock -2.2. Summary Information -2.3. Cylinder groups -2.4. Fragments -2.5. Updates to the file system -.LP -.sp .5v -.nf -.B "3. Fixing corrupted file systems -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. File system connectivity -.LP -.sp .5v -.nf -.B Acknowledgements -.LP -.sp .5v -.nf -.B References -.LP -.sp .5v -.nf -.B "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 -.ds RH Introduction -.bp diff --git a/sbin/fsck/SMM.doc/1.t b/sbin/fsck/SMM.doc/1.t deleted file mode 100644 index 4d2f535..0000000 --- a/sbin/fsck/SMM.doc/1.t +++ /dev/null @@ -1,83 +0,0 @@ -.\" Copyright (c) 1982, 1993 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" -.\" @(#)1.t 8.1 (Berkeley) 6/5/93 -.\" -.ds RH Introduction -.NH -Introduction -.PP -This document reflects the use of -.I fsck -with the 4.2BSD and 4.3BSD file system organization. This -is a revision of the -original paper written by -T. J. Kowalski. -.PP -When a UNIX -operating system is brought up, a consistency -check of the file systems should always be performed. -This precautionary measure helps to insure -a reliable environment for file storage on disk. -If an inconsistency is discovered, -corrective action must be taken. -.I Fsck -runs in two modes. -Normally it is run non-interactively by the system after -a normal boot. -When running in this mode, -it will only make changes to the file system that are known -to always be correct. -If an unexpected inconsistency is found -.I fsck -will exit with a non-zero exit status, -leaving the system running single-user. -Typically the operator then runs -.I fsck -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. -.PP -The purpose of this memo is to dispel the -mystique surrounding -file system inconsistencies. -It first describes the updating of the file system -(the calm before the storm) and -then describes file system corruption (the storm). -Finally, -the set of deterministic corrective actions -used by -.I fsck -(the Coast Guard -to the rescue) is presented. -.ds RH Overview of the File System diff --git a/sbin/fsck/SMM.doc/2.t b/sbin/fsck/SMM.doc/2.t deleted file mode 100644 index 7d00cea..0000000 --- a/sbin/fsck/SMM.doc/2.t +++ /dev/null @@ -1,265 +0,0 @@ -.\" Copyright (c) 1982, 1993 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" -.\" @(#)2.t 8.1 (Berkeley) 6/5/93 -.\" -.ds RH Overview of the file system -.NH -Overview of the file system -.PP -The file system is discussed in detail in [Mckusick84]; -this section gives a brief overview. -.NH 2 -Superblock -.PP -A file system is described by its -.I "super-block" . -The super-block is built when the file system is created (\c -.I newfs (8)) -and never changes. -The super-block -contains the basic parameters of the file system, -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, -.I newfs -replicates it to protect against catastrophic loss. -The -.I "default super block" -always resides at a fixed offset from the beginning -of the file system's disk partition. -The -.I "redundant 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. -.PP -Within the file system are files. -Certain files are distinguished as directories and contain collections -of pointers to files that may themselves be directories. -Every file has a descriptor associated with it called an -.I "inode". -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\(dg. -.FS -\(dgThe actual number may vary from system to system, but is usually in -the range 5-13. -.FE -The inode structure may also contain references to indirect blocks -containing further data block indices. -In a file system 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). -.PP -In order to create files with up to -2\(ua32 bytes, -using only two levels of indirection, -the minimum size of a file system block is 4096 bytes. -The size of file system blocks can be any power of two -greater than or equal to 4096. -The block size of the file system is maintained in the super-block, -so it is possible for file systems of different block sizes -to be accessible simultaneously on the same system. -The block size must be decided when -.I newfs -creates the file system; -the block size cannot be subsequently -changed without rebuilding the file system. -.NH 2 -Summary information -.PP -Associated with the super block is non replicated -.I "summary information" . -The summary information changes -as the file system is modified. -The summary information contains -the number of blocks, fragments, inodes and directories in the file system. -.NH 2 -Cylinder groups -.PP -The file system partitions the disk into one or more areas called -.I "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 -.I "block map" -describing available blocks in the cylinder group, -and summary information describing the usage of data blocks -within the cylinder group. -A fixed number of inodes is allocated for each cylinder group -when the file system is created. -The current policy is to allocate one inode for each 2048 -bytes of disk space; -this is expected to be far more inodes than will ever be needed. -.PP -All the cylinder group bookkeeping information could be -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 destroyed the top platter -could cause the loss of all copies of the redundant super-blocks. -Thus the cylinder group bookkeeping information -begins at a floating offset from the beginning of the cylinder group. -The offset for -the -.I "i+1" st -cylinder group is about one track further -from the beginning of the cylinder group -than it was for the -.I "i" th -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 beginning of the cylinder group -and the beginning of the cylinder group information stores data. -.NH 2 -Fragments -.PP -To avoid waste in storing small files, -the file system space allocator divides a single -file system block into one or more -.I "fragments". -The fragmentation of the file system is specified -when the file system is created; -each file system 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 determine block availability. -.PP -On a file system 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 file system 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 file system. -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. -.NH 2 -Updates to the file system -.PP -Every working day hundreds of files -are created, modified, and removed. -Every time a file is modified, -the operating system performs a -series of file system updates. -These updates, when written on disk, yield a consistent file system. -The file system stages -all modifications of critical information; -modification can -either be completed or cleanly backed out after a crash. -Knowing the information that is first written to the file system, -deterministic procedures can be developed to -repair a corrupted file system. -To understand this process, -the order that the update -requests were being honored must first be understood. -.PP -When a user program does an operation to change the file system, -such as a -.I write , -the data to be written is copied into an internal -.I "in-core" -buffer in the kernel. -Normally, 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 -.I write -system call has returned. -Thus at any given time, the file system, -as it resides on the disk, -lags the state of the file system represented by the in-core information. -.PP -The disk information is updated to reflect the in-core information -when the buffer is required for another use, -when a -.I sync (2) -is done (at 30 second intervals) by -.I "/etc/update" "(8)," -or by manual operator intervention with the -.I sync (8) -command. -If the system is halted without writing out the in-core information, -the file system on the disk will be in an inconsistent state. -.PP -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. -.PP -The problem with asynchronous inode updates -can be avoided by doing all inode deallocations synchronously. -Consequently, -inodes and indirect blocks are written to the disk synchronously -(\fIi.e.\fP the process blocks until the information is -really written to disk) -when they are being deallocated. -Similarly inodes are kept consistent by synchronously -deleting, adding, or changing directory entries. -.ds RH Fixing corrupted file systems diff --git a/sbin/fsck/SMM.doc/3.t b/sbin/fsck/SMM.doc/3.t deleted file mode 100644 index bb6f05b..0000000 --- a/sbin/fsck/SMM.doc/3.t +++ /dev/null @@ -1,452 +0,0 @@ -.\" Copyright (c) 1982, 1993 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" -.\" @(#)3.t 8.1 (Berkeley) 6/5/93 -.\" -.ds RH Fixing corrupted file systems -.NH -Fixing corrupted file systems -.PP -A file system -can become corrupted in several ways. -The most common of these ways are -improper shutdown procedures -and hardware failures. -.PP -File systems may become corrupted during an -.I "unclean halt" . -This happens when proper shutdown -procedures are not observed, -physically write-protecting a mounted file system, -or a mounted file system is taken off-line. -The most common operator procedural failure is forgetting to -.I sync -the system before halting the CPU. -.PP -File systems may become further corrupted if proper startup -procedures are not observed, e.g., -not checking a file system for inconsistencies, -and not repairing inconsistencies. -Allowing a corrupted file system to be used (and, thus, to be modified -further) can be disastrous. -.PP -Any piece of hardware can fail at any time. -Failures -can be as subtle as a bad block -on a disk pack, or as blatant as a non-functional disk-controller. -.NH 2 -Detecting and correcting corruption -.PP -Normally -.I fsck -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 -.I fsck -will take when it is running interactively. -Throughout this paper we assume that -.I fsck -is being run interactively, -and all possible errors can be encountered. -When an inconsistency is discovered in this mode, -.I fsck -reports the inconsistency for the operator to -chose a corrective action. -.PP -A quiescent\(dd -.FS -\(dd I.e., unmounted and not being written on. -.FE -file system may be checked for structural integrity -by performing consistency checks on the -redundant data intrinsic to a file system. -The redundant data is either read from -the file system, -or computed from other known values. -The file system -.B must -be in a quiescent state when -.I fsck -is run, -since -.I fsck -is a multi-pass program. -.PP -In the following sections, -we discuss methods to discover inconsistencies -and possible corrective actions -for the cylinder group blocks, the inodes, the indirect blocks, and -the data blocks containing directory entries. -.NH 2 -Super-block checking -.PP -The most commonly corrupted item in a file system -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 file -system's blocks or inodes, -and is usually corrupted -after an unclean halt. -.PP -The super-block is checked for inconsistencies -involving file-system size, number of inodes, -free-block count, and the free-inode count. -The file-system 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 file-system size and layout information -are the most critical pieces of information for -.I fsck . -While there is no way to actually check these sizes, -since they are statically determined by -.I newfs , -.I fsck -can check that these sizes are within reasonable bounds. -All other file system checks require that these sizes be correct. -If -.I fsck -detects corruption in the static parameters of the default super-block, -.I fsck -requests the operator to specify the location of an alternate super-block. -.NH 2 -Free block checking -.PP -.I Fsck -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, -.I fsck -checks that -the number of free blocks -plus the number of blocks claimed by the inodes -equals the total number of blocks in the file system. -.PP -If anything is wrong with the block allocation maps, -.I fsck -will rebuild them, -based on the list it has computed of allocated blocks. -.PP -The summary information associated with the super-block -counts the total number of free blocks within the file system. -.I Fsck -compares this count to the -number of free blocks it found within the file system. -If the two counts do not agree, then -.I fsck -replaces the incorrect count in the summary information -by the actual free-block count. -.PP -The summary information -counts the total number of free inodes within the file system. -.I Fsck -compares this count to the number -of free inodes it found within the file system. -If the two counts do not agree, then -.I fsck -replaces the incorrect count in the -summary information by the actual free-inode count. -.NH 2 -Checking the inode state -.PP -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. -.PP -The list of inodes in the file system -is checked sequentially starting with inode 2 -(inode 0 marks unused inodes; -inode 1 is saved for future generations) -and progressing through the last inode in the file system. -The state of each inode is checked for -inconsistencies involving format and type, -link count, -duplicate blocks, -bad blocks, -and inode size. -.PP -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 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 -.I fsck -is to clear the inode. -.NH 2 -Inode links -.PP -Each inode counts the -total number of directory entries -linked to the inode. -.I Fsck -verifies the link count of each inode -by starting at the root of the file system, -and descending through the directory structure. -The actual link count for each inode -is calculated during the descent. -.PP -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, -.I fsck -will place the disconnected file in the -.I 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, -.I fsck -replaces the incorrect stored link count by the actual link count. -.PP -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. -.PP -.I Fsck -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 -.I "duplicate blocks" . -Otherwise, the list of allocated blocks -is updated to include the block number. -.PP -If there are any duplicate blocks, -.I fsck -will perform 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 available -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 happens, -.I fsck -prompts the operator to clear both inodes. -The operator must decide which one should be kept -and which one should be cleared. -.PP -.I Fsck -checks the range of each block number claimed by an inode. -If the block number is -lower than the first data block in the file system, -or greater than the last data block, -then the block number is a -.I "bad block number" . -Many bad blocks in an inode are usually caused by -an indirect block that was not written to the file system, -a condition which can only occur if there has been a hardware failure. -If an inode contains bad block numbers, -.I fsck -prompts the operator to clear it. -.NH 2 -Inode data size -.PP -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. -.I Fsck -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 -.I fsck -prompts the operator to fix it. -.PP -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 comparing that expected block count against -the actual number of blocks the inode claims. -.NH 2 -Checking the data associated with an inode -.PP -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; -symbolic link data blocks -contain the path name stored in a link. -Directory data blocks contain directory entries. -.I Fsck -can only check the validity of directory data blocks. -.PP -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 file system, -incorrect directory inode numbers for ``\fB.\fP'' and ``\fB..\fP'', -and directories that are not attached to the file system. -If the inode number in a directory data block -references an unallocated inode, -then -.I fsck -will remove that directory entry. -Again, -this condition can only arise when there has been a hardware failure. -.PP -.I Fsck -also checks for directories with unallocated blocks (holes). -Such directories should never be created. -When found, -.I 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 preceeding the hole. -Unfortunately, this means that another Phase 1 run has to be done. -.I Fsck -will remind the user to rerun fsck after repairing a -directory containing an unallocated block. -.PP -If a directory entry inode number references -outside the inode list, then -.I fsck -will remove that directory entry. -This condition occurs if bad data is written into a directory data block. -.PP -The directory inode number entry for ``\fB.\fP'' -must be the first entry in the directory data block. -The inode number for ``\fB.\fP'' -must reference itself; -e.g., it must equal the inode number -for the directory data block. -The directory inode number entry -for ``\fB..\fP'' 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, -.I fsck -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 ``\fB..\fP'' should point; -\fIfsck\fP recommends deletion for the subsequently discovered names. -.NH 2 -File system connectivity -.PP -.I Fsck -checks the general connectivity of the file system. -If directories are not linked into the file system, then -.I fsck -links the directory back into the file system in the -.I lost+found -directory. -This condition only occurs when there has been a hardware failure. -.ds RH "References" -.SH -\s+2Acknowledgements\s0 -.PP -I thank Bill Joy, Sam Leffler, Robert Elz and Dennis Ritchie -for their suggestions and help in implementing the new file system. -Thanks also to Robert Henry for his editorial 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) -.PP -I would like to thank Larry A. Wehr for advice that lead -to the first version of -.I fsck -and Rick B. Brandt for adapting -.I fsck -to -UNIX/TS. (T. Kowalski, July 1979) -.sp 2 -.SH -\s+2References\s0 -.LP -.IP [Dolotta78] 20 -Dolotta, T. A., and Olsson, S. B. eds., -.I "UNIX User's Manual, Edition 1.1\^" , -January 1978. -.IP [Joy83] 20 -Joy, W., Cooper, E., Fabry, R., Leffler, S., McKusick, M., and Mosher, D. -4.2BSD System Manual, -.I "University of California at Berkeley" , -.I "Computer Systems Research Group Technical Report" -#4, 1982. -.IP [McKusick84] 20 -McKusick, M., Joy, W., Leffler, S., and Fabry, R. -A Fast File System for UNIX, -\fIACM Transactions on Computer Systems 2\fP, 3. -pp. 181-197, August 1984. -.IP [Ritchie78] 20 -Ritchie, D. M., and Thompson, K., -The UNIX Time-Sharing System, -.I "The Bell System Technical Journal" -.B 57 , -6 (July-August 1978, Part 2), pp. 1905-29. -.IP [Thompson78] 20 -Thompson, K., -UNIX Implementation, -.I "The Bell System Technical Journal\^" -.B 57 , -6 (July-August 1978, Part 2), pp. 1931-46. -.ds RH Appendix A \- Fsck Error Conditions -.bp diff --git a/sbin/fsck/SMM.doc/4.t b/sbin/fsck/SMM.doc/4.t deleted file mode 100644 index 5ea8179..0000000 --- a/sbin/fsck/SMM.doc/4.t +++ /dev/null @@ -1,1424 +0,0 @@ -.\" Copyright (c) 1982, 1993 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" -.\" @(#)4.t 8.1 (Berkeley) 6/5/93 -.\" -.ds RH Appendix A \- Fsck Error Conditions -.NH -Appendix A \- Fsck Error Conditions -.NH 2 -Conventions -.PP -.I Fsck -is -a multi-pass file system check program. -Each file system pass invokes a different Phase of the -.I fsck -program. -After the initial setup, -.I fsck -performs successive Phases over each file system, -checking blocks and sizes, -path-names, -connectivity, -reference counts, -and the map of free blocks, -(possibly rebuilding it), -and performs some cleanup. -.LP -Normally -.I fsck -is run non-interactively to -.I preen -the file systems after an unclean halt. -While preen'ing a file system, -it will only fix corruptions that are expected -to occur from an unclean halt. -These actions are a proper subset of the actions that -.I fsck -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, -.I fsck -reports the error condition to the operator. -If a response is required, -.I fsck -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. -.LP -The error conditions are organized by the -.I Phase -of the -.I fsck -program in which they can occur. -The error conditions that may occur -in more than one Phase -will be discussed in initialization. -.NH 2 -Initialization -.PP -Before a file system check can be performed, certain -tables have to be set up and certain files opened. -This section concerns itself with the opening of files and -the initialization of tables. -This section lists error conditions resulting from -command line options, -memory requests, -opening of files, -status of files, -file system size checks, -and creation of the scratch file. -All the initialization errors are fatal -when the file system is being preen'ed. -.sp -.LP -.B "\fIC\fP option?" -.br -\fIC\fP is not a legal option to -.I fsck ; -legal options are \-b, \-c, \-y, \-n, and \-p. -.I Fsck -terminates on this error condition. -See the -.I fsck (8) -manual entry for further detail. -.sp -.LP -.B "cannot alloc NNN bytes for blockmap" -.br -.B "cannot alloc NNN bytes for freemap" -.br -.B "cannot alloc NNN bytes for statemap" -.br -.B "cannot alloc NNN bytes for lncntp" -.br -.I Fsck 's -request for memory for its virtual -memory tables failed. -This should never happen. -.I Fsck -terminates on this error condition. -See a guru. -.sp -.LP -.B "Can't open checklist file: \fIF\fP" -.br -The file system checklist file -\fIF\fP (usually -.I /etc/fstab ) -can not be opened for reading. -.I Fsck -terminates on this error condition. -Check access modes of \fIF\fP. -.sp -.LP -.B "Can't stat root" -.br -.I Fsck 's -request for statistics about the root directory ``/'' failed. -This should never happen. -.I Fsck -terminates on this error condition. -See a guru. -.sp -.LP -.B "Can't stat \fIF\fP" -.br -.B "Can't make sense out of name \fIF\fP" -.br -.I Fsck 's -request for statistics about the file system \fIF\fP failed. -When running manually, -it ignores this file system -and continues checking the next file system given. -Check access modes of \fIF\fP. -.sp -.LP -.B "Can't open \fIF\fP" -.br -.I Fsck 's -request attempt to open the file system \fIF\fP failed. -When running manually, it ignores this file system -and continues checking the next file system given. -Check access modes of \fIF\fP. -.sp -.LP -.B "\fIF\fP: (NO WRITE)" -.br -Either the \-n flag was specified or -.I fsck 's -attempt to open the file system \fIF\fP for writing failed. -When running manually, -all the diagnostics are printed out, -but no modifications are attempted to fix them. -.sp -.LP -.B "file is not a block or character device; OK" -.br -You have given -.I fsck -a regular file name by mistake. -Check the type of the file specified. -.LP -Possible responses to the OK prompt are: -.IP YES -ignore this error condition. -.IP NO -ignore this file system and continues checking -the next file system given. -.sp -.LP -.B "UNDEFINED OPTIMIZATION IN SUPERBLOCK (SET TO DEFAULT)" -.br -The superblock optimization parameter is neither OPT_TIME -nor OPT_SPACE. -.LP -Possible responses to the SET TO DEFAULT prompt are: -.IP YES -The superblock is set to request optimization to minimize -running time of the system. -(If optimization to minimize disk space utilization is -desired, it can be set using \fItunefs\fP(8).) -.IP NO -ignore this error condition. -.sp -.LP -.B "IMPOSSIBLE MINFREE=\fID\fP IN SUPERBLOCK (SET TO DEFAULT)" -.br -The superblock minimum space percentage is greater than 99% -or less then 0%. -.LP -Possible responses to the SET TO DEFAULT prompt are: -.IP YES -The minfree parameter is set to 10%. -(If some other percentage is desired, -it can be set using \fItunefs\fP(8).) -.IP NO -ignore this error condition. -.sp -.LP -.B "IMPOSSIBLE INTERLEAVE=\fID\fP IN SUPERBLOCK (SET TO DEFAULT)" -.br -The file system interleave is less than or equal to zero. -.LP -Possible responses to the SET TO DEFAULT prompt are: -.IP YES -The interleave parameter is set to 1. -.IP NO -ignore this error condition. -.sp -.LP -.B "IMPOSSIBLE NPSECT=\fID\fP IN SUPERBLOCK (SET TO DEFAULT)" -.br -The number of physical sectors per track is less than the number -of usable sectors per track. -.LP -Possible responses to the SET TO DEFAULT prompt are: -.IP YES -The npsect parameter is set to the number of usable sectors per track. -.IP NO -ignore this error condition. -.sp -.LP -One of the following messages will appear: -.br -.B "MAGIC NUMBER WRONG" -.br -.B "NCG OUT OF RANGE" -.br -.B "CPG OUT OF RANGE" -.br -.B "NCYL DOES NOT JIVE WITH NCG*CPG" -.br -.B "SIZE PREPOSTEROUSLY LARGE" -.br -.B "TRASHED VALUES IN SUPER BLOCK" -.br -and will be followed by the message: -.br -.B "\fIF\fP: BAD SUPER BLOCK: \fIB\fP" -.br -.B "USE -b OPTION TO FSCK TO SPECIFY LOCATION OF AN ALTERNATE" -.br -.B "SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; SEE fsck(8)." -.br -The super block has been corrupted. -An alternative super block must be selected from among those -listed by -.I newfs -(8) when the file system was created. -For file systems with a blocksize less than 32K, -specifying \-b 32 is a good first choice. -.sp -.LP -.B "INTERNAL INCONSISTENCY: \fIM\fP" -.br -.I Fsck 's -has had an internal panic, whose message is specified as \fIM\fP. -This should never happen. -See a guru. -.sp -.LP -.B "CAN NOT SEEK: BLK \fIB\fP (CONTINUE)" -.br -.I Fsck 's -request for moving to a specified block number \fIB\fP in -the file system failed. -This should never happen. -See a guru. -.LP -Possible responses to the CONTINUE prompt are: -.IP YES -attempt to continue to run the file system check. -Often, -however the problem will persist. -This error condition will not allow a complete check of the file system. -A second run of -.I fsck -should be made to re-check this file system. -If the block was part of the virtual memory buffer -cache, -.I fsck -will terminate with the message ``Fatal I/O error''. -.IP NO -terminate the program. -.sp -.LP -.B "CAN NOT READ: BLK \fIB\fP (CONTINUE)" -.br -.I Fsck 's -request for reading a specified block number \fIB\fP in -the file system failed. -This should never happen. -See a guru. -.LP -Possible responses to the CONTINUE prompt are: -.IP YES -attempt to continue to run the file system check. -It will retry the read and print out the message: -.br -.B "THE FOLLOWING SECTORS COULD NOT BE READ: \fIN\fP" -.br -where \fIN\fP indicates the sectors that could not be read. -If -.I fsck -ever tries to write back one of the blocks on which the read failed -it will print the message: -.br -.B "WRITING ZERO'ED BLOCK \fIN\fP TO DISK" -.br -where \fIN\fP 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 file system. -A second run of -.I fsck -should be made to re-check this file system. -If the block was part of the virtual memory buffer -cache, -.I fsck -will terminate with the message ``Fatal I/O error''. -.IP NO -terminate the program. -.sp -.LP -.B "CAN NOT WRITE: BLK \fIB\fP (CONTINUE)" -.br -.I Fsck 's -request for writing a specified block number \fIB\fP -in the file system failed. -The disk is write-protected; -check the write protect lock on the drive. -If that is not the problem, see a guru. -.LP -Possible responses to the CONTINUE prompt are: -.IP YES -attempt to continue to run the file system check. -The write operation will be retried with the failed blocks -indicated by the message: -.br -.B "THE FOLLOWING SECTORS COULD NOT BE WRITTEN: \fIN\fP" -.br -where \fIN\fP indicates the sectors that could not be written. -If the disk is experiencing hardware problems, the problem will persist. -This error condition will not allow a complete check of the file system. -A second run of -.I fsck -should be made to re-check this file system. -If the block was part of the virtual memory buffer -cache, -.I fsck -will terminate with the message ``Fatal I/O error''. -.IP NO -terminate the program. -.sp -.LP -.B "bad inode number DDD to ginode" -.br -An internal error has attempted to read non-existent inode \fIDDD\fP. -This error causes -.I fsck -to exit. -See a guru. -.NH 2 -Phase 1 \- Check Blocks and Sizes -.PP -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 -.B "INCORRECT BLOCK COUNT" -and -.B "PARTIALLY TRUNCATED INODE" -are fatal if the file system is being preen'ed. -.sp -.LP -.B "UNKNOWN FILE TYPE I=\fII\fP (CLEAR)" -.br -The mode word of the inode \fII\fP indicates that the inode is not a -special block inode, special character inode, socket inode, regular inode, -symbolic link, or directory inode. -.LP -Possible responses to the CLEAR prompt are: -.IP YES -de-allocate inode \fII\fP by zeroing its contents. -This will always invoke the UNALLOCATED error condition in Phase 2 -for each directory entry pointing to this inode. -.IP NO -ignore this error condition. -.sp -.LP -.B "PARTIALLY TRUNCATED INODE I=\fII\fP (SALVAGE)" -.br -.I Fsck -has found inode \fII\fP 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 file system, -.I fsck -completes the truncation to the specified size. -.LP -Possible responses to SALVAGE are: -.IP YES -complete the truncation to the size specified in the inode. -.IP NO -ignore this error condition. -.sp -.LP -.B "LINK COUNT TABLE OVERFLOW (CONTINUE)" -.br -An internal table for -.I fsck -containing allocated inodes with a link count of -zero cannot allocate more memory. -Increase the virtual memory for -.I fsck . -.LP -Possible responses to the CONTINUE prompt are: -.IP YES -continue with the program. -This error condition will not allow a complete check of the file system. -A second run of -.I fsck -should be made to re-check this file system. -If another allocated inode with a zero link count is found, -this error condition is repeated. -.IP NO -terminate the program. -.sp -.LP -.B "\fIB\fP BAD I=\fII\fP" -.br -Inode \fII\fP contains block number \fIB\fP with a number -lower than the number of the first data block in the file system or -greater than the number of the last block -in the file system. -This error condition may invoke the -.B "EXCESSIVE BAD BLKS" -error condition in Phase 1 (see next paragraph) if -inode \fII\fP has too many block numbers outside the file system range. -This error condition will always invoke the -.B "BAD/DUP" -error condition in Phase 2 and Phase 4. -.sp -.LP -.B "EXCESSIVE BAD BLKS I=\fII\fP (CONTINUE)" -.br -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 file system or greater than -the number of last block in the file system associated with inode \fII\fP. -.LP -Possible responses to the CONTINUE prompt are: -.IP YES -ignore the rest of the blocks in this inode -and continue checking with the next inode in the file system. -This error condition will not allow a complete check of the file system. -A second run of -.I fsck -should be made to re-check this file system. -.IP NO -terminate the program. -.sp -.LP -.B "BAD STATE DDD TO BLKERR" -.br -An internal error has scrambled -.I fsck 's -state map to have the impossible value \fIDDD\fP. -.I Fsck -exits immediately. -See a guru. -.sp -.LP -.B "\fIB\fP DUP I=\fII\fP" -.br -Inode \fII\fP contains block number \fIB\fP that is already claimed by -another inode. -This error condition may invoke the -.B "EXCESSIVE DUP BLKS" -error condition in Phase 1 if -inode \fII\fP has too many block numbers claimed by other inodes. -This error condition will always invoke Phase 1b and the -.B "BAD/DUP" -error condition in Phase 2 and Phase 4. -.sp -.LP -.B "EXCESSIVE DUP BLKS I=\fII\fP (CONTINUE)" -.br -There is more than a tolerable number (usually 10) of blocks claimed by other -inodes. -.LP -Possible responses to the CONTINUE prompt are: -.IP YES -ignore the rest of the blocks in this inode -and continue checking with the next inode in the file system. -This error condition will not allow a complete check of the file system. -A second run of -.I fsck -should be made to re-check this file system. -.IP NO -terminate the program. -.sp -.LP -.B "DUP TABLE OVERFLOW (CONTINUE)" -.br -An internal table in -.I fsck -containing duplicate block numbers cannot allocate any more space. -Increase the amount of virtual memory available to -.I fsck . -.LP -Possible responses to the CONTINUE prompt are: -.IP YES -continue with the program. -This error condition will not allow a complete check of the file system. -A second run of -.I fsck -should be made to re-check this file system. -If another duplicate block is found, this error condition will repeat. -.IP NO -terminate the program. -.sp -.LP -.B "PARTIALLY ALLOCATED INODE I=\fII\fP (CLEAR)" -.br -Inode \fII\fP is neither allocated nor unallocated. -.LP -Possible responses to the CLEAR prompt are: -.IP YES -de-allocate inode \fII\fP by zeroing its contents. -.IP NO -ignore this error condition. -.sp -.LP -.B "INCORRECT BLOCK COUNT I=\fII\fP (\fIX\fP should be \fIY\fP) (CORRECT)" -.br -The block count for inode \fII\fP is \fIX\fP blocks, -but should be \fIY\fP blocks. -When preen'ing the count is corrected. -.LP -Possible responses to the CORRECT prompt are: -.IP YES -replace the block count of inode \fII\fP with \fIY\fP. -.IP NO -ignore this error condition. -.NH 2 -Phase 1B: Rescan for More Dups -.PP -When a duplicate block is found in the file system, the file system is -rescanned to find the inode that previously claimed that block. -This section lists the error condition when the duplicate block is found. -.sp -.LP -.B "\fIB\fP DUP I=\fII\fP" -.br -Inode \fII\fP contains block number \fIB\fP that -is already claimed by another inode. -This error condition will always invoke the -.B "BAD/DUP" -error condition in Phase 2. -You can determine which inodes have overlapping blocks by examining -this error condition and the DUP error condition in Phase 1. -.NH 2 -Phase 2 \- Check Pathnames -.PP -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 file system is being preen'ed, -except for directories not being a multiple of the blocks size -and extraneous hard links. -.sp -.LP -.B "ROOT INODE UNALLOCATED (ALLOCATE)" -.br -The root inode (usually inode number 2) has no allocate mode bits. -This should never happen. -.LP -Possible responses to the ALLOCATE prompt are: -.IP 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 -.I lost+found . -If the attempt to allocate the root fails, -.I fsck -will exit with the message: -.br -.B "CANNOT ALLOCATE ROOT INODE" . -.IP NO -.I fsck -will exit. -.sp -.LP -.B "ROOT INODE NOT DIRECTORY (REALLOCATE)" -.br -The root inode (usually inode number 2) -is not directory inode type. -.LP -Possible responses to the REALLOCATE prompt are: -.IP YES -clear the existing contents of the root inode -and reallocate it. -The files and directories usually found in the root will be recovered -in Phase 3 and put into -.I lost+found . -If the attempt to allocate the root fails, -.I fsck -will exit with the message: -.br -.B "CANNOT ALLOCATE ROOT INODE" . -.IP NO -.I fsck -will then prompt with -.B "FIX" -.LP -Possible responses to the FIX prompt are: -.IP 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. -.IP NO -terminate the program. -.sp -.LP -.B "DUPS/BAD IN ROOT INODE (REALLOCATE)" -.br -Phase 1 or Phase 1b have found duplicate blocks -or bad blocks in the root inode (usually inode number 2) for the file system. -.LP -Possible responses to the REALLOCATE prompt are: -.IP YES -clear the existing contents of the root inode -and reallocate it. -The files and directories usually found in the root will be recovered -in Phase 3 and put into -.I lost+found . -If the attempt to allocate the root fails, -.I fsck -will exit with the message: -.br -.B "CANNOT ALLOCATE ROOT INODE" . -.IP NO -.I fsck -will then prompt with -.B "CONTINUE" . -.LP -Possible responses to the CONTINUE prompt are: -.IP YES -ignore the -.B "DUPS/BAD" -error condition in the root inode and -attempt to continue to run the file system check. -If the root inode is not correct, -then this may result in many other error conditions. -.IP NO -terminate the program. -.sp -.LP -.B "NAME TOO LONG \fIF\fP" -.br -An excessively long path name has been found. -This usually indicates loops in the file system name space. -This can occur if the super user has made circular links to directories. -The offending links must be removed (by a guru). -.sp -.LP -.B "I OUT OF RANGE I=\fII\fP NAME=\fIF\fP (REMOVE)" -.br -A directory entry \fIF\fP has an inode number \fII\fP that is greater than -the end of the inode list. -.LP -Possible responses to the REMOVE prompt are: -.IP YES -the directory entry \fIF\fP is removed. -.IP NO -ignore this error condition. -.sp -.LP -.B "UNALLOCATED I=\fII\fP OWNER=\fIO\fP MODE=\fIM\fP SIZE=\fIS\fP MTIME=\fIT\fP \fItype\fP=\fIF\fP (REMOVE)" -.br -A directory or file entry \fIF\fP points to an unallocated inode \fII\fP. -The owner \fIO\fP, mode \fIM\fP, size \fIS\fP, modify time \fIT\fP, -and name \fIF\fP are printed. -.LP -Possible responses to the REMOVE prompt are: -.IP YES -the directory entry \fIF\fP is removed. -.IP NO -ignore this error condition. -.sp -.LP -.B "DUP/BAD I=\fII\fP OWNER=\fIO\fP MODE=\fIM\fP SIZE=\fIS\fP MTIME=\fIT\fP \fItype\fP=\fIF\fP (REMOVE)" -.br -Phase 1 or Phase 1b have found duplicate blocks or bad blocks -associated with directory or file entry \fIF\fP, inode \fII\fP. -The owner \fIO\fP, mode \fIM\fP, size \fIS\fP, modify time \fIT\fP, -and directory name \fIF\fP are printed. -.LP -Possible responses to the REMOVE prompt are: -.IP YES -the directory entry \fIF\fP is removed. -.IP NO -ignore this error condition. -.sp -.LP -.B "ZERO LENGTH DIRECTORY I=\fII\fP OWNER=\fIO\fP MODE=\fIM\fP SIZE=\fIS\fP MTIME=\fIT\fP DIR=\fIF\fP (REMOVE)" -.br -A directory entry \fIF\fP has a size \fIS\fP that is zero. -The owner \fIO\fP, mode \fIM\fP, size \fIS\fP, modify time \fIT\fP, -and directory name \fIF\fP are printed. -.LP -Possible responses to the REMOVE prompt are: -.IP YES -the directory entry \fIF\fP is removed; -this will always invoke the BAD/DUP error condition in Phase 4. -.IP NO -ignore this error condition. -.sp -.LP -.B "DIRECTORY TOO SHORT I=\fII\fP OWNER=\fIO\fP MODE=\fIM\fP SIZE=\fIS\fP MTIME=\fIT\fP DIR=\fIF\fP (FIX)" -.br -A directory \fIF\fP has been found whose size \fIS\fP -is less than the minimum size directory. -The owner \fIO\fP, mode \fIM\fP, size \fIS\fP, modify time \fIT\fP, -and directory name \fIF\fP are printed. -.LP -Possible responses to the FIX prompt are: -.IP YES -increase the size of the directory to the minimum directory size. -.IP NO -ignore this directory. -.sp -.LP -.B "DIRECTORY \fIF\fP LENGTH \fIS\fP NOT MULTIPLE OF \fIB\fP (ADJUST) -.br -A directory \fIF\fP has been found with size \fIS\fP that is not -a multiple of the directory blocksize \fIB\fP. -.LP -Possible responses to the ADJUST prompt are: -.IP YES -the length is rounded up to the appropriate block size. -This error can occur on 4.2BSD file systems. -Thus when preen'ing the file system only a warning is printed -and the directory is adjusted. -.IP NO -ignore the error condition. -.sp -.LP -.B "DIRECTORY CORRUPTED I=\fII\fP OWNER=\fIO\fP MODE=\fIM\fP SIZE=\fIS\fP MTIME=\fIT\fP DIR=\fIF\fP (SALVAGE)" -.br -A directory with an inconsistent internal state has been found. -.LP -Possible responses to the FIX prompt are: -.IP YES -throw away all entries up to the next directory boundary (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. -.IP NO -skip up to the next directory boundary and resume reading, -but do not modify the directory. -.sp -.LP -.B "BAD INODE NUMBER FOR `.' I=\fII\fP OWNER=\fIO\fP MODE=\fIM\fP SIZE=\fIS\fP MTIME=\fIT\fP DIR=\fIF\fP (FIX)" -.br -A directory \fII\fP has been found whose inode number for `.' does -does not equal \fII\fP. -.LP -Possible responses to the FIX prompt are: -.IP YES -change the inode number for `.' to be equal to \fII\fP. -.IP NO -leave the inode number for `.' unchanged. -.sp -.LP -.B "MISSING `.' I=\fII\fP OWNER=\fIO\fP MODE=\fIM\fP SIZE=\fIS\fP MTIME=\fIT\fP DIR=\fIF\fP (FIX)" -.br -A directory \fII\fP has been found whose first entry is unallocated. -.LP -Possible responses to the FIX prompt are: -.IP YES -build an entry for `.' with inode number equal to \fII\fP. -.IP NO -leave the directory unchanged. -.sp -.LP -.B "MISSING `.' I=\fII\fP OWNER=\fIO\fP MODE=\fIM\fP SIZE=\fIS\fP MTIME=\fIT\fP DIR=\fIF\fP" -.br -.B "CANNOT FIX, FIRST ENTRY IN DIRECTORY CONTAINS \fIF\fP" -.br -A directory \fII\fP has been found whose first entry is \fIF\fP. -.I Fsck -cannot resolve this problem. -The file system should be mounted and the offending entry \fIF\fP -moved elsewhere. -The file system should then be unmounted and -.I fsck -should be run again. -.sp -.LP -.B "MISSING `.' I=\fII\fP OWNER=\fIO\fP MODE=\fIM\fP SIZE=\fIS\fP MTIME=\fIT\fP DIR=\fIF\fP" -.br -.B "CANNOT FIX, INSUFFICIENT SPACE TO ADD `.'" -.br -A directory \fII\fP has been found whose first entry is not `.'. -.I Fsck -cannot resolve this problem as it should never happen. -See a guru. -.sp -.LP -.B "EXTRA `.' ENTRY I=\fII\fP OWNER=\fIO\fP MODE=\fIM\fP SIZE=\fIS\fP MTIME=\fIT\fP DIR=\fIF\fP (FIX)" -.br -A directory \fII\fP has been found that has more than one entry for `.'. -.LP -Possible responses to the FIX prompt are: -.IP YES -remove the extra entry for `.'. -.IP NO -leave the directory unchanged. -.sp -.LP -.B "BAD INODE NUMBER FOR `..' I=\fII\fP OWNER=\fIO\fP MODE=\fIM\fP SIZE=\fIS\fP MTIME=\fIT\fP DIR=\fIF\fP (FIX)" -.br -A directory \fII\fP has been found whose inode number for `..' does -does not equal the parent of \fII\fP. -.LP -Possible responses to the FIX prompt are: -.IP YES -change the inode number for `..' to be equal to the parent of \fII\fP -(``\fB..\fP'' in the root inode points to itself). -.IP NO -leave the inode number for `..' unchanged. -.sp -.LP -.B "MISSING `..' I=\fII\fP OWNER=\fIO\fP MODE=\fIM\fP SIZE=\fIS\fP MTIME=\fIT\fP DIR=\fIF\fP (FIX)" -.br -A directory \fII\fP has been found whose second entry is unallocated. -.LP -Possible responses to the FIX prompt are: -.IP YES -build an entry for `..' with inode number equal to the parent of \fII\fP -(``\fB..\fP'' in the root inode points to itself). -.IP NO -leave the directory unchanged. -.sp -.LP -.B "MISSING `..' I=\fII\fP OWNER=\fIO\fP MODE=\fIM\fP SIZE=\fIS\fP MTIME=\fIT\fP DIR=\fIF\fP" -.br -.B "CANNOT FIX, SECOND ENTRY IN DIRECTORY CONTAINS \fIF\fP" -.br -A directory \fII\fP has been found whose second entry is \fIF\fP. -.I Fsck -cannot resolve this problem. -The file system should be mounted and the offending entry \fIF\fP -moved elsewhere. -The file system should then be unmounted and -.I fsck -should be run again. -.sp -.LP -.B "MISSING `..' I=\fII\fP OWNER=\fIO\fP MODE=\fIM\fP SIZE=\fIS\fP MTIME=\fIT\fP DIR=\fIF\fP" -.br -.B "CANNOT FIX, INSUFFICIENT SPACE TO ADD `..'" -.br -A directory \fII\fP has been found whose second entry is not `..'. -.I Fsck -cannot resolve this problem. -The file system should be mounted and the second entry in the directory -moved elsewhere. -The file system should then be unmounted and -.I fsck -should be run again. -.sp -.LP -.B "EXTRA `..' ENTRY I=\fII\fP OWNER=\fIO\fP MODE=\fIM\fP SIZE=\fIS\fP MTIME=\fIT\fP DIR=\fIF\fP (FIX)" -.br -A directory \fII\fP has been found that has more than one entry for `..'. -.LP -Possible responses to the FIX prompt are: -.IP YES -remove the extra entry for `..'. -.IP NO -leave the directory unchanged. -.sp -.LP -.B "\fIN\fP IS AN EXTRANEOUS HARD LINK TO A DIRECTORY \fID\fP (REMOVE) -.br -.I Fsck -has found a hard link, \fIN\fP, to a directory, \fID\fP. -When preen'ing the extraneous links are ignored. -.LP -Possible responses to the REMOVE prompt are: -.IP YES -delete the extraneous entry, \fIN\fP. -.IP NO -ignore the error condition. -.sp -.LP -.B "BAD INODE \fIS\fP TO DESCEND" -.br -An internal error has caused an impossible state \fIS\fP to be passed to the -routine that descends the file system directory structure. -.I Fsck -exits. -See a guru. -.sp -.LP -.B "BAD RETURN STATE \fIS\fP FROM DESCEND" -.br -An internal error has caused an impossible state \fIS\fP to be returned -from the routine that descends the file system directory structure. -.I Fsck -exits. -See a guru. -.sp -.LP -.B "BAD STATE \fIS\fP FOR ROOT INODE" -.br -An internal error has caused an impossible state \fIS\fP to be assigned -to the root inode. -.I Fsck -exits. -See a guru. -.NH 2 -Phase 3 \- Check Connectivity -.PP -This phase concerns itself with the directory connectivity seen in -Phase 2. -This section lists error conditions resulting from -unreferenced directories, -and missing or full -.I lost+found -directories. -.sp -.LP -.B "UNREF DIR I=\fII\fP OWNER=\fIO\fP MODE=\fIM\fP SIZE=\fIS\fP MTIME=\fIT\fP (RECONNECT)" -.br -The directory inode \fII\fP was not connected to a directory entry -when the file system was traversed. -The owner \fIO\fP, mode \fIM\fP, size \fIS\fP, and -modify time \fIT\fP of directory inode \fII\fP are printed. -When preen'ing, the directory is reconnected if its size is non-zero, -otherwise it is cleared. -.LP -Possible responses to the RECONNECT prompt are: -.IP YES -reconnect directory inode \fII\fP to the file system in the -directory for lost files (usually \fIlost+found\fP). -This may invoke the -.I lost+found -error condition in Phase 3 -if there are problems connecting directory inode \fII\fP to \fIlost+found\fP. -This may also invoke the CONNECTED error condition in Phase 3 if the link -was successful. -.IP NO -ignore this error condition. -This will always invoke the UNREF error condition in Phase 4. -.sp -.LP -.B "NO lost+found DIRECTORY (CREATE)" -.br -There is no -.I lost+found -directory in the root directory of the file system; -When preen'ing -.I fsck -tries to create a \fIlost+found\fP directory. -.LP -Possible responses to the CREATE prompt are: -.IP YES -create a \fIlost+found\fP directory in the root of the file system. -This may raise the message: -.br -.B "NO SPACE LEFT IN / (EXPAND)" -.br -See below for the possible responses. -Inability to create a \fIlost+found\fP directory generates the message: -.br -.B "SORRY. CANNOT CREATE lost+found DIRECTORY" -.br -and aborts the attempt to linkup the lost inode. -This will always invoke the UNREF error condition in Phase 4. -.IP NO -abort the attempt to linkup the lost inode. -This will always invoke the UNREF error condition in Phase 4. -.sp -.LP -.B "lost+found IS NOT A DIRECTORY (REALLOCATE)" -.br -The entry for -.I lost+found -is not a directory. -.LP -Possible responses to the REALLOCATE prompt are: -.IP YES -allocate a directory inode, and change \fIlost+found\fP to reference it. -The previous inode reference by the \fIlost+found\fP 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 \fIlost+found\fP directory generates the message: -.br -.B "SORRY. CANNOT CREATE lost+found DIRECTORY" -.br -and aborts the attempt to linkup the lost inode. -This will always invoke the UNREF error condition in Phase 4. -.IP NO -abort the attempt to linkup the lost inode. -This will always invoke the UNREF error condition in Phase 4. -.sp -.LP -.B "NO SPACE LEFT IN /lost+found (EXPAND)" -.br -There is no space to add another entry to the -.I lost+found -directory in the root directory -of the file system. -When preen'ing the -.I lost+found -directory is expanded. -.LP -Possible responses to the EXPAND prompt are: -.IP YES -the -.I lost+found -directory is expanded to make room for the new entry. -If the attempted expansion fails -.I fsck -prints the message: -.br -.B "SORRY. NO SPACE IN lost+found DIRECTORY" -.br -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 -.I lost+found . -This error is fatal if the file system is being preen'ed. -.IP NO -abort the attempt to linkup the lost inode. -This will always invoke the UNREF error condition in Phase 4. -.sp -.LP -.B "DIR I=\fII1\fP CONNECTED. PARENT WAS I=\fII2\fP" -.br -This is an advisory message indicating a directory inode \fII1\fP was -successfully connected to the -.I lost+found -directory. -The parent inode \fII2\fP of the directory inode \fII1\fP is -replaced by the inode number of the -.I lost+found -directory. -.sp -.LP -.B "DIRECTORY \fIF\fP LENGTH \fIS\fP NOT MULTIPLE OF \fIB\fP (ADJUST) -.br -A directory \fIF\fP has been found with size \fIS\fP that is not -a multiple of the directory blocksize \fIB\fP -(this can reoccur in Phase 3 if it is not adjusted in Phase 2). -.LP -Possible responses to the ADJUST prompt are: -.IP YES -the length is rounded up to the appropriate block size. -This error can occur on 4.2BSD file systems. -Thus when preen'ing the file system only a warning is printed -and the directory is adjusted. -.IP NO -ignore the error condition. -.sp -.LP -.B "BAD INODE \fIS\fP TO DESCEND" -.br -An internal error has caused an impossible state \fIS\fP to be passed to the -routine that descends the file system directory structure. -.I Fsck -exits. -See a guru. -.NH 2 -Phase 4 \- Check Reference Counts -.PP -This phase concerns itself with the link count information -seen in Phase 2 and Phase 3. -This section lists error conditions resulting from -unreferenced files, -missing or full -.I 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 file system is being preen'ed -except running out of space in the \fIlost+found\fP directory. -.sp -.LP -.B "UNREF FILE I=\fII\fP OWNER=\fIO\fP MODE=\fIM\fP SIZE=\fIS\fP MTIME=\fIT\fP (RECONNECT)" -.br -Inode \fII\fP was not connected to a directory entry -when the file system was traversed. -The owner \fIO\fP, mode \fIM\fP, size \fIS\fP, and -modify time \fIT\fP of inode \fII\fP are printed. -When preen'ing the file is cleared if either its size or its -link count is zero, -otherwise it is reconnected. -.LP -Possible responses to the RECONNECT prompt are: -.IP YES -reconnect inode \fII\fP to the file system in the directory for -lost files (usually \fIlost+found\fP). -This may invoke the -.I lost+found -error condition in Phase 4 -if there are problems connecting inode \fII\fP to -.I lost+found . -.IP NO -ignore this error condition. -This will always invoke the CLEAR error condition in Phase 4. -.sp -.LP -.B "(CLEAR)" -.br -The inode mentioned in the immediately previous error condition can not be -reconnected. -This cannot occur if the file system is being preen'ed, -since lack of space to reconnect files is a fatal error. -.LP -Possible responses to the CLEAR prompt are: -.IP YES -de-allocate the inode mentioned in the immediately previous error condition by zeroing its contents. -.IP NO -ignore this error condition. -.sp -.LP -.B "NO lost+found DIRECTORY (CREATE)" -.br -There is no -.I lost+found -directory in the root directory of the file system; -When preen'ing -.I fsck -tries to create a \fIlost+found\fP directory. -.LP -Possible responses to the CREATE prompt are: -.IP YES -create a \fIlost+found\fP directory in the root of the file system. -This may raise the message: -.br -.B "NO SPACE LEFT IN / (EXPAND)" -.br -See below for the possible responses. -Inability to create a \fIlost+found\fP directory generates the message: -.br -.B "SORRY. CANNOT CREATE lost+found DIRECTORY" -.br -and aborts the attempt to linkup the lost inode. -This will always invoke the UNREF error condition in Phase 4. -.IP NO -abort the attempt to linkup the lost inode. -This will always invoke the UNREF error condition in Phase 4. -.sp -.LP -.B "lost+found IS NOT A DIRECTORY (REALLOCATE)" -.br -The entry for -.I lost+found -is not a directory. -.LP -Possible responses to the REALLOCATE prompt are: -.IP YES -allocate a directory inode, and change \fIlost+found\fP to reference it. -The previous inode reference by the \fIlost+found\fP 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 \fIlost+found\fP directory generates the message: -.br -.B "SORRY. CANNOT CREATE lost+found DIRECTORY" -.br -and aborts the attempt to linkup the lost inode. -This will always invoke the UNREF error condition in Phase 4. -.IP NO -abort the attempt to linkup the lost inode. -This will always invoke the UNREF error condition in Phase 4. -.sp -.LP -.B "NO SPACE LEFT IN /lost+found (EXPAND)" -.br -There is no space to add another entry to the -.I lost+found -directory in the root directory -of the file system. -When preen'ing the -.I lost+found -directory is expanded. -.LP -Possible responses to the EXPAND prompt are: -.IP YES -the -.I lost+found -directory is expanded to make room for the new entry. -If the attempted expansion fails -.I fsck -prints the message: -.br -.B "SORRY. NO SPACE IN lost+found DIRECTORY" -.br -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 -.I lost+found . -This error is fatal if the file system is being preen'ed. -.IP NO -abort the attempt to linkup the lost inode. -This will always invoke the UNREF error condition in Phase 4. -.sp -.LP -.B "LINK COUNT \fItype\fP I=\fII\fP OWNER=\fIO\fP MODE=\fIM\fP SIZE=\fIS\fP MTIME=\fIT\fP COUNT=\fIX\fP SHOULD BE \fIY\fP (ADJUST)" -.br -The link count for inode \fII\fP, -is \fIX\fP but should be \fIY\fP. -The owner \fIO\fP, mode \fIM\fP, size \fIS\fP, and modify time \fIT\fP -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, -.I fsck -exits with the message: -.br -.B "LINK COUNT INCREASING" -.LP -Possible responses to the ADJUST prompt are: -.IP YES -replace the link count of file inode \fII\fP with \fIY\fP. -.IP NO -ignore this error condition. -.sp -.LP -.B "UNREF \fItype\fP I=\fII\fP OWNER=\fIO\fP MODE=\fIM\fP SIZE=\fIS\fP MTIME=\fIT\fP (CLEAR)" -.br -Inode \fII\fP, was not connected to a directory entry when the -file system was traversed. -The owner \fIO\fP, mode \fIM\fP, size \fIS\fP, -and modify time \fIT\fP of inode \fII\fP -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. -.LP -Possible responses to the CLEAR prompt are: -.IP YES -de-allocate inode \fII\fP by zeroing its contents. -.IP NO -ignore this error condition. -.sp -.LP -.B "BAD/DUP \fItype\fP I=\fII\fP OWNER=\fIO\fP MODE=\fIM\fP SIZE=\fIS\fP MTIME=\fIT\fP (CLEAR)" -.br -Phase 1 or Phase 1b have found duplicate blocks -or bad blocks associated with -inode \fII\fP. -The owner \fIO\fP, mode \fIM\fP, size \fIS\fP, -and modify time \fIT\fP of inode \fII\fP -are printed. -This error cannot arise when the file system is being preen'ed, -as it would have caused a fatal error earlier. -.LP -Possible responses to the CLEAR prompt are: -.IP YES -de-allocate inode \fII\fP by zeroing its contents. -.IP NO -ignore this error condition. -.NH 2 -Phase 5 - Check Cyl groups -.PP -This phase concerns itself with the free-block and used-inode maps. -This section lists error conditions resulting 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. -.sp -.LP -.B "CG \fIC\fP: BAD MAGIC NUMBER" -.br -The magic number of cylinder group \fIC\fP is wrong. -This usually indicates that the cylinder group maps have been destroyed. -When running manually the cylinder group is marked as needing -to be reconstructed. -This error is fatal if the file system is being preen'ed. -.sp -.LP -.B "BLK(S) MISSING IN BIT MAPS (SALVAGE)" -.br -A cylinder group block map is missing some free blocks. -During preen'ing the maps are reconstructed. -.LP -Possible responses to the SALVAGE prompt are: -.IP YES -reconstruct the free block map. -.IP NO -ignore this error condition. -.sp -.LP -.B "SUMMARY INFORMATION BAD (SALVAGE)" -.br -The summary information was found to be incorrect. -When preen'ing, -the summary information is recomputed. -.LP -Possible responses to the SALVAGE prompt are: -.IP YES -reconstruct the summary information. -.IP NO -ignore this error condition. -.sp -.LP -.B "FREE BLK COUNT(S) WRONG IN SUPERBLOCK (SALVAGE)" -.br -The superblock free block information was found to be incorrect. -When preen'ing, -the superblock free block information is recomputed. -.LP -Possible responses to the SALVAGE prompt are: -.IP YES -reconstruct the superblock free block information. -.IP NO -ignore this error condition. -.NH 2 -Cleanup -.PP -Once a file system has been checked, a few cleanup functions are performed. -This section lists advisory messages about -the file system -and modify status of the file system. -.sp -.LP -.B "\fIV\fP files, \fIW\fP used, \fIX\fP free (\fIY\fP frags, \fIZ\fP blocks)" -.br -This is an advisory message indicating that -the file system checked contained -\fIV\fP files using -\fIW\fP fragment sized blocks leaving -\fIX\fP fragment sized blocks free in the file system. -The numbers in parenthesis breaks the free count down into -\fIY\fP free fragments and -\fIZ\fP free full sized blocks. -.sp -.LP -.B "***** REBOOT UNIX *****" -.br -This is an advisory message indicating that -the root file system has been modified by -.I fsck. -If UNIX is not rebooted immediately, -the work done by -.I fsck -may be undone by the in-core copies of tables -UNIX keeps. -When preen'ing, -.I fsck -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. -.sp -.LP -.B "***** FILE SYSTEM WAS MODIFIED *****" -.br -This is an advisory message indicating that -the current file system was modified by -.I fsck. -If this file system is mounted or is the current root file system, -.I fsck -should be halted and UNIX rebooted. -If UNIX is not rebooted immediately, -the work done by -.I fsck -may be undone by the in-core copies of tables -UNIX keeps. diff --git a/sbin/fsck/SMM.doc/Makefile b/sbin/fsck/SMM.doc/Makefile deleted file mode 100644 index 26823bc..0000000 --- a/sbin/fsck/SMM.doc/Makefile +++ /dev/null @@ -1,7 +0,0 @@ -# @(#)Makefile 8.1 (Berkeley) 6/8/93 - -DIR= smm/03.fsck -SRCS= 0.t 1.t 2.t 3.t 4.t -MACROS= -ms - -.include <bsd.doc.mk> |
