0207-0209.html
来自「linux-unix130.linux.and.unix.ebooks130 l」· HTML 代码 · 共 373 行
HTML
373 行
<HTML>
<HEAD>
<TITLE>Developer.com - Online Reference Library - 0672311739:RED HAT LINUX 2ND EDITION:Filesystems, Disks, and Other Devices</TITLE>
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<SCRIPT>
<!--
function displayWindow(url, width, height) {
var Win = window.open(url,"displayWindow",'width=' + width +
',height=' + height + ',resizable=1,scrollbars=yes');
}
//-->
</SCRIPT>
</HEAD>
-->
<!-- ISBN=0672311739 //-->
<!-- TITLE=RED HAT LINUX 2ND EDITION //-->
<!-- AUTHOR=DAVID PITTS ET AL //-->
<!-- PUBLISHER=MACMILLAN //-->
<!-- IMPRINT=SAMS PUBLISHING //-->
<!-- PUBLICATION DATE=1998 //-->
<!-- CHAPTER=11 //-->
<!-- PAGES=0195-0228 //-->
<!-- UNASSIGNED1 //-->
<!-- UNASSIGNED2 //-->
<P><CENTER>
<a href="0204-0206.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0210-0212.html">Next</A>
</CENTER></P>
<A NAME="PAGENUM-207"><P>Page 207</P></A>
<H3><A NAME="ch11_ 10">
Repairing Filesystems
</A></H3>
<P>Some disk data is kept in memory temporarily before being written to disk, for
performance reasons (see the previous discussion of the
sync mount option). If the kernel does not have an opportunity to actually write this data, the filesystem can become corrupted. This can
happen in several ways:
</P>
<UL>
<LI> The storage device (for example, a floppy disk) can be manually removed before
the kernel has finished with it.
<LI> The system might suffer a power loss.
<LI> The user might mistakenly turn off the power or accidentally press the reset button.
</UL>
<P>As part of the boot process, Linux runs the
fsck program, whose job it is to check and repair filesystems. Most of the time the boot follows a controlled shutdown (see the manual page
for shutdown), and in this case, the filesystems will have been unmounted before the reboot. In
this case, fsck says that they are "clean." It knows this because before unmounting them, the
kernel writes a special signature on the filesystem to indicate that the data is intact. When
the filesystem is mounted again for writing, this signature is removed.
</P>
<P>If, on the other hand, one of the disasters listed takes place, the filesystems will not be
marked "clean," and when fsck is invoked, as usual, it will notice this and begin a full check of
the filesystem. This also occurs if you specify the
-f flag to fsck. To prevent errors creeping up on it,
fsck also enforces a periodic check; a full check is done at an interval specified on the
filesystem itself (usually every 20 boots or 6 months, whichever comes sooner), even if it was
unmounted cleanly.
</P>
<P>The boot process (see Chapter 4) checks the root filesystem and then mounts it
read/write. (It's mounted read-only by the kernel;
fsck asks for confirmation before operating on a
read/write filesystem, and this is not desirable for
an unattended reboot.) First, the root filesystem
is checked with the following command:
</P>
<!-- CODE SNIP //-->
<PRE>
fsck -V -a /
</PRE>
<!-- END CODE SNIP //-->
<P>Then all the other filesystems are checked by executing this command:
</P>
<!-- CODE SNIP //-->
<PRE>
fsck -R -A -V -a
</PRE>
<!-- END CODE SNIP //-->
<P>These options specify that all the filesystems should be checked
(-A) except the root filesystem, which doesn't need checking a second time
(-R), and that operations produce informational messages about what it is doing as it goes
(-V), but that the process should not be interactive
(-a). The latter is done because, for example, there might not be anyone present to answer
any questions from fsck.
</P>
<A NAME="PAGENUM-208"><P>Page 208</P></A>
<P>In the case of serious filesystem corruption, the approach breaks down because there are
some things that fsck will not do to a filesystem without your say-so. In this case, it returns an
error value to its caller (the startup script), and the startup script spawns a shell to allow the
administrator to run fsck interactively. When this has happened, this message appears:
</P>
<!-- CODE //-->
<PRE>
*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
Give root password for maintenance
(or type Control-D for normal startup):
</PRE>
<!-- END CODE //-->
<P>This is a very troubling event, particularly because it might well appear if you have other
problems with the system—for example, a lockup (leading you to press the reset button) or
a spontaneous reboot. None of the online manuals are guaranteed to be available at this
stage, because they might be stored on the filesystem whose check failed. This prompt is issued if
the root filesystem check failed, or the filesystem check failed for any of the other disk filesystems.
</P>
<P>When the automatic fsck fails, you need to log in by specifying the
root password and run the fsck program manually. When you have typed in the root password, you are presented
with the following prompt:
</P>
<!-- CODE SNIP //-->
<PRE>
(Repair filesystem) #
</PRE>
<!-- END CODE SNIP //-->
<P>You might worry about what command to enter here, or indeed what to do at all. At least
one of the filesystems needs to be checked, but which one? The preceding messages from
fsck should indicate which, but it isn't necessary to go hunting for them. There is a set of options you
can give fsck that tells it to check everything manually, and this is a good fallback:
</P>
<!-- CODE SNIP //-->
<PRE>
fsck -A -V ; echo == $? ==
</PRE>
<!-- END CODE SNIP //-->
<P>This is the same command as the previous one, but the
-R option is missing, in case the root filesystem needs to be checked, and the
-a option is missing, so fsck is in its "interactive"
mode. This might enable a check to succeed just because it can now ask you questions. The
purpose of the echo == $? == command is to unambiguously interpret the outcome of the
fsck operation. If the value printed between the equals signs is less than 4, all is well. If this value is
4 or more, more recovery measures are needed. The meanings of the various values returned are
as follows:
</P>
<TABLE WIDTH="360">
<TR><TD>
0
</TD><TD>
</TD><TD>
No errors
</TD></TR>
<TR><TD>
1
</TD><TD>
</TD><TD>
Filesystem errors corrected
</TD></TR>
<TR><TD>
2
</TD><TD>
</TD><TD>
System should be rebooted
</TD></TR>
<TR><TD>
4
</TD><TD>
</TD><TD>
Filesystem errors left uncorrected
</TD></TR>
<TR><TD>
8
</TD><TD>
</TD><TD>
Operational error
</TD></TR>
<TR><TD>
16
</TD><TD>
</TD><TD>
Usage or syntax error
</TD></TR>
<TR><TD>
128
</TD><TD>
</TD><TD>
Shared library error
</TD></TR>
</TABLE>
<A NAME="PAGENUM-209"><P>Page 209</P></A>
<P>If this does not work, this might be because of a
corrupted superblock—fsck starts its disk
check and if this is corrupted, it can't start. By good design, the
ext2 filesystem has many backup superblocks scattered regularly throughout the filesystem. Suppose the command
announces that it has failed to clean some particular filesystem—for example,
/dev/fubar. You can start fsck again, using a backup superblock by using the following command:
</P>
<!-- CODE SNIP //-->
<PRE>
fsck -t ext2 -b 8193 /dev/fubar
</PRE>
<!-- END CODE SNIP //-->
<P>8193 is the block number for the first backup superblock. This backup superblock is at
the start of block group 1 (the first is numbered 0). There are more backup superblocks at the
start of block group 2 (16385), and block group 3 (24577); they are spaced at intervals of
8192 blocks. If you made a filesystem with settings other than the defaults, these might change.
mke2fs lists the superblocks that it creates as it goes, so that is a good time to pay attention if you're
not using the default settings. There are further things you can attempt if
fsck is still not succeeding, but these are very rare and usually indicate hardware problems so severe that they
prevent the proper operation of fsck. Examples include broken wires in the IDE connector cable
and similar nasty problems. If this command still fails, you might seek expert help or try to fix
the disk in a different machine.
</P>
<P>These extreme measures are very unlikely; a manual
fsck, in the unusual circumstance where it is actually required, almost always fixes things. After the manual
fsck has worked, the root shell that the startup scripts provide has done its purpose. Type
exit to exit it. At this point, in order to make sure that everything goes according to plan, the boot process is started
again from the beginning. This second time around, the filesystems should all be error-free and
the system should boot normally.
</P>
<H3><A NAME="ch11_ 11">
Hardware
</A></H3>
<P>There are block devices under Linux for representing all sorts of random access
devices—floppy disks, hard disks (XT, EIDE, and SCSI), Zip drives, CD-ROM drives, ramdisks, and
loopback devices.
</P>
<H4><A NAME="ch11_ 12">
Hard Disks
</A></H4>
<P>Hard disks are large enough to make it useful to keep different filesystems on different parts
of the hard disk. The scheme for dividing these disks up is called
partitioning. Although it is common for computers running MS-DOS to have only one partition, it is possible to have
several different partitions on each disk. The summary of how the disk is partitioned is kept in
its partition table.
</P>
<H4><A NAME="ch11_ 13">
The Partition Table
</A></H4>
<P>A hard disk might be divided up like this:
</P>
<P><CENTER>
<a href="0204-0206.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0210-0212.html">Next</A>
</CENTER></P>
</td>
</tr>
</table>
<!-- begin footer information -->
</body></html>⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?