151 lines
8.0 KiB
Plaintext
151 lines
8.0 KiB
Plaintext
Fsck is a File System Consistency checKer. It checks Minixfs filesystems for
|
|
consistency and optionally repairs them too. It is important that a Minixfs
|
|
filesystem is checked for errors when, for example, the system crashes or a
|
|
lock up forces a reboot when programs are using the filesystems. This will
|
|
occasionally mean that fsck will perform minor repairs which will cause no
|
|
damage at all. Using a damaged filesystems can result in much more serious
|
|
damage occuring at a later date which require more destructive repairs to
|
|
fix.
|
|
|
|
ADVICE ON USE OF FSCK
|
|
|
|
fsck cannot perform miracles; a severely damaged filesystem (such as if a lot
|
|
of sectors get wiped somehow) may have very little salvageable. However, don't
|
|
be overwhelmed by the options available. In practice only fsck -n or fsck on
|
|
its own are used, the -p option is useful in shell scripts where non-interactive
|
|
repair is needed, but you dont want any attempted destructive repair.
|
|
|
|
If fsck -n does produce what appear like a lot of serious errors then it might
|
|
be an idea to attempt to backup the data before trying repairs; of course if
|
|
you have a full backup (you do make regular backups don't you?) available it
|
|
might be best to forget about repair altogether and just reinitialize the
|
|
filesystem (with minit) and restore from backup.
|
|
|
|
USING FSCK
|
|
|
|
Fsck can be used in interactive or non-interactive mode. In interactive mode
|
|
you are prompted before each fix. In non-interactive mode, repairs are carried
|
|
out automatically or not at all. The option '-y' carries out all repairs that
|
|
fsck would suggest, the '-p' (preen) option carries out all repairs if the
|
|
Minixfs filesystems is only slighlty damaged and can be repaired without
|
|
destroying data, the '-n' option only prints out the damage: it does not
|
|
repair anything. The '-y' option is not recommended, unless you are sure it
|
|
is what you want.
|
|
|
|
The options are followed by the drive letter of the partition you want to
|
|
check for example,
|
|
fsck -p D:
|
|
|
|
REPAIRS CARRIED OUT
|
|
|
|
In order to know precisely what repairs are carried out you must know a litle
|
|
about the internal structure of a Minixfs filesystem. Each filesystem is
|
|
divided into blocks or zones, these are always 1K in size.
|
|
|
|
Each directory/file/symbolic link has an inode associated with it. This is
|
|
a small part of a disk sector which carries all information about a file
|
|
except its name. It contains the file access modes (including what kind of
|
|
entity the inode refers to) as well as it's size and a list of sectors where
|
|
the file can be found. If this list is not large enough then an 'indirection
|
|
block' which is a disk block containing a list of further blocks belonging to
|
|
the file is used (and recorded in the inode). If this is not enough then a
|
|
'double indirection block' is used containing a list of further indirection
|
|
blocks. With this information, all the data in a file can be accessed.
|
|
|
|
A directory is basically identical to a file except it has a different mode
|
|
number. The 'data' in this file is a list of 'entries' (or links) each entry
|
|
contains a filename and an inode number where that name can be found. The root
|
|
directory is always contained in inode 1. A field in the inode called it's
|
|
'link count' gives a count of the number directory entries that refer to it.
|
|
Every directory has two filenames '.' which refers to itself and '..' which
|
|
refers to the parent directory. The only exception is the root directory where
|
|
'..' refers to itself as well.
|
|
|
|
Each used inode/block is referenced in a bitmap. If the filesystem crashes
|
|
before this can be written out to disk then it will be inaccurate. Fortunately
|
|
fsck can rebuild the bitmaps from the data contained in inodes. This is what
|
|
the prompts asking about bitmap repair mean. They are harmless and it is
|
|
strongly advised that any bitmap repairs suggested are made.
|
|
|
|
If you use the filesystem and some used blocks do not have their bits set in
|
|
the bitmap then other files can use them, overwriting the original data. These
|
|
are called 'multiply allocated blocks'. fsck will give a list of these blocks
|
|
and (optionally) allow you to decide which inode is the valid block. Usually
|
|
the valid data is contained in the file with the latest modify time: the '-y'
|
|
option removes all of the references. By finding the files the inodes
|
|
refer to (e.g. with the -i option) you can look to see which file
|
|
contains the valid data and then interactively remove the other references.
|
|
The other files where the references are removed then have 'holes' in them,
|
|
you may want to try to recover them or just delete them after 'fsck' has done
|
|
its work. This is why it is important that the bitmaps are accurate and should
|
|
be checked regularly.
|
|
|
|
This is the 'best case' scenario of multiply allocated blocks. If the block
|
|
overwritten belongs to a directory then much more trouble is caused. After
|
|
deleting the overwritten reference in a directory lots of inodes may no
|
|
longer be referenced in a directory, these are called 'orphaned' inodes (they
|
|
have no parent directory). fsck has no way of knowing their original names,
|
|
but the data is recoverable. fsck makes entries for these inodes in a
|
|
directory called lost+found . The name chosen is simply the inode number. You
|
|
can then analyse the files/directories in lost+found and delete, rename or move
|
|
them to where they were originally.
|
|
|
|
The worst case is if an indirection block is overwritten. This can cause lots
|
|
of spurious messages about bad zone numbers and other multiply allocated blocks.
|
|
fsck cannot currently help much under such circumstances: if a certain inode
|
|
contains lots of multiple block number or bad zone numbers then it's best to
|
|
delete all multiply allocated blocks in that inode; either with fsck or finding
|
|
the inode on the disk and deleting the associated file.
|
|
|
|
Here is a summary of the possible repairs fsck performs:
|
|
|
|
1. Scan all inodes, allow deletion of multiply allocated blocks, inodes with
|
|
bad modes, truncation of inodes which reference too many zones.
|
|
|
|
2. Scan all directories, check for valid names and the existance of '.' and
|
|
'..' entries and allow fixing.
|
|
|
|
3. Check filesystem conectivity (that each inode has a directory entry) and
|
|
allow repair of any problems and reconnection of orphaned inodes.
|
|
|
|
4. Check bitmaps and repair; check inode link counts and allow repair.
|
|
|
|
MISCELLANEOUS OPTIONS
|
|
|
|
If the root directory gets destroyed it must be handled separately because the
|
|
lost+found directory will be killed also. If this is the case then the '-R'
|
|
option will reform the root directory. Unfortunately the directory increment
|
|
is determined from the root directory, so you must manually tell fsck the
|
|
directory increment with the '-d' option followed by the increment. If you
|
|
get this wrong then a large number of errors about directory entries will
|
|
be erroneously reported.
|
|
If for some reason the root inode is no longer a directory Minixfs
|
|
may get confused and not recognise the filesystem anymore. By asking fsck to
|
|
continue it will still check the root inode as though it were a directory: if
|
|
it looks OK fsck allows you to make it a directory again. However you will
|
|
have to reboot before the filesystem will be recognised by Minixfs again.
|
|
|
|
The '-i' option followed by a comma separated list of numbers will
|
|
print out the pathnames of the corresponding inodes. E.g. fsck -i 1,2,3 D:
|
|
This will print out *all* the possible names so e.g. fsck -i 1 d: may
|
|
give something like:
|
|
|
|
\.
|
|
\..
|
|
\dir\..
|
|
\dir2\..
|
|
etc.
|
|
|
|
The '-z' option allows an inode to be zeroed if for example it is
|
|
severely trashed and fixing would do more harm than good (e.g. if an
|
|
indirection block has been overwritten). -z may be followed by a comma
|
|
separated list of inodes to zero. NB use this option with extreme caution,
|
|
the data the inode refers to will be effectively deleted (it will still be
|
|
on the disk but no longer accessible directly). Using this option will also
|
|
cause related "errors" to appear (though all can be fixed) such as inode
|
|
and bitmap errors and links a free inode.
|
|
|
|
The '-e' option tries to find out the filesystem size by reading
|
|
as far as it can through a partition: this is an experimental option and
|
|
isn't too useful at present.
|