Crawly Crypt Collection 2/crawlyvol2.bin/alt_os/mint/mfs6011/source/docs/fsck.doc

Text File | 1995-01-01 | 8KB | 151 lines

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.