UNIX系统管理－第九章：修复文件系统
目标
完成这一章，你将能做以下事情:
理解文件系统是如何进行更新操作的
理解sync是如何预防文件系统错误
列出文件系统错误的三个原因
使用fsck检查和修补文件系统
文件系统的维护
日常的维护
－检查文件系统的一致性
－执行文件系统备份
－监控磁盘的使用情况
系统管理员的一个主要的职责就是保护用户的数据的安全。

由于UNIX中数据通过文件系统的方式存储，系统会强制性检查文件系统的存储环境是否出现问题。

文件系统的完整性十分重要，系统管理员可以做许多工作来保护文件系统的完整性。

这一章，我们会学习如何使用fsck工具来检查和维护文件系统的完整性。

在开始之前，我们需要了解文件系统的更新是如何发生的。

文件系统的更新
当一个文件系统装载后，它的超级块被拷贝到内存中。

当拷贝完成之后，文件系统的标记被置为“dirty”。

所有的对超级块的更改首先要去更改这个拷贝。

当一个SYNC的系统调用使用的时候，磁盘上的拷贝才会被更新。

当一个文件系统被卸载的时候，所有的在内存中的数据会被写回到磁盘上，文件系统的标记被置为“clean"。

所有的对metadata进行的修改首先是修改其在内存中的拷贝，然后才会被写到磁盘上去。

一些metadata的修改是立即写到磁盘上，其它的则是在调用sync的时候才会被写到磁盘上。

举一个例子：rm myfile命令会引起以下的一些改变：
1.myfile的目录的条目被清除。

2.用来描述myfile的inode被释放
3.用来索引剩余数据块和剩余inode的映射图被更新
4.超级块中的剩余数据块的数量和inode的数量被更新
不幸的是，不是所有的metadata数据都是连续地存储在磁盘上的，所以它会进行一系列的写操作来完成这些处理过程，如果在进行这些过程中系统突然崩溃，就会使metadata数据产生不一致。

例如：如果myfile的目录条目已经被清除，但是inode还没有被释放，结果就是一个inode有一个链接，但是并没有目录结构指向这个inode。

这就是不一致的metadata。

内存缓冲区
用户写数据的时候，实际上并不立即发生写磁盘的动作，数据会被拷贝到一个内存的缓冲区里。

这个操作非常快，数据同inode信息一起，会在以后的一些时间被写到磁盘上，通常是在缓冲区满的时候和新需要清除一下缓冲空间的时候。

如果系统在还没有将缓冲区中的信息写到磁盘上去之前，系统关闭。

文件系统的一致性就会被破坏。

如果你察觉文件系统已经被破坏，你应该停止当前的工作。

使用缓冲区的优点和缺点:
使用缓冲区可以对磁盘进行均匀的存取，因为内核不需要知道磁盘I/O的产生的原因，内核只会将缓冲区中的数据写到磁盘，而不用去关心缓冲区数据的组成。

从磁盘I/O的观点来看，使用缓冲区，系统的设计会更简单。

通过使用缓冲区，应用程序会很容易地移植到其它的UNIX系统上去，因为不同的UNIX机器的磁盘I/O也许会不同，但是程序不需要了解这些。

它们只是写到缓冲区，而不用去考虑磁盘的设置方式。

使用缓冲区可以减少对磁盘的读写，这会提高整个系统的响应时间，换句话说，系统运行更快了。

重复利用缓冲区中的数据文件也能够加速系统的响应。

刷新缓冲区
sync
将缓冲区的内容写到磁盘
保持文件系统为最新
通常是通过syncer守护进程来激活
syncer
syncer是在系统启动的过程中自动启动。

syncer程序的语法为：
syncer[seconds]
数据在写磁盘上之前会先写被到一个缓冲区里。

而缓冲区写到磁盘会有一个延迟，直到：
系统需要缓冲区进行其它的操作
最后的块被修改
文件系统被卸载
sync命令被执行
系统关闭或者重启动
syncer
syncer通常是在系统启动的时候，在/sbin/init.d/syncer脚本文件中启动的，它的职责就是定时刷新缓冲区。

你不需要手工执行syncer命令，它会在系统启动的时候，自动通过/sbin/init.d/syncer 脚本执行。

sync
sync执行sync这个系统调用。

执行这个命令会刷新还没有写到磁盘上的系统缓冲区数据，包括修改的超级块，修改过的inode，和延迟的块I/O，这会确保在执行一个关键的操作如系统关闭之前，所有的文件修改都会被写到磁盘上去。

而你可以在任何时候手工执行这个命令。

sync会自动执行syncer守护进程周期执行的所有操作。

介绍fsck
为什么要运行fsck?
检查文件系统metadata的完整性
在需要的时候修补metadata数据的损坏
什么时候执行fsck？
在系统异常关闭的时候，会自动运行这个命令。

系统管理员怀疑文件系统被破坏的时候，也可以手工运行这个命令。

当操作系统非正常关闭的时候，文件系统的更改可能会丢失或者未完成。

fsck工具在系统崩溃或者未正常关闭的时候会自动运行，它会验证你的文件系统的完整性。

这个工具会试图修改任何能够识别的数据错误。

fsck在系统非正常关闭时会自动运行，但是你也可以在怀疑文件系统有错误的时候手工运行这个命令。

运行fsck
例子：在/dev/vg01/myfs2下运行fsck
1.mount -v
2.umount /dev/vg01/myfs2
3.fsck -F hfs /dev/vg01/rmyfs2
4 mount /dev/vg01/myfs2
5. 恢复任何被破坏的文件：
问题
fsck删除任何文件吗？
fsck重新连接任何文件吗？
运行fsck要进行的步骤：
1.mount -v
使用这个命令来判断每一个一个文件系统装载的目标。

和文件系统的类型，因为你在运行fsck的时候必须要知道文件类型。

2.umount /dev/vg01/myfs1
umount /dev/vg01/myfs2
fsck必须在一个静态的文件系统上运行，因此在执行命令之前要卸载文件系统.
3.fsck -F vxfs /dev/vg01/rmyfs1
fsck -F hfs /dev/vg01/rmyfs2
在运行fsck的时候，你必须要指明你要检查的文件系统的类型。

为了达到最优的性能，你也可以指明包含文件系统的逻辑卷或者磁盘的裸设备文件名。

如果fsck检查到一个文件系统不完整，它会报告这个问题，然后询问是否对其进行修复。

如果你回答”yes”，fsck会试图修正这个问题。

如果你回答“no”，fsck会忽略这个问题，继续进行检查。

一般都要选择"yes"，让系统自动修复发现的问题。

4.mount /dev/vg01/myfs1
mount /dev/vg01/myfs2
在fsck完成之后，重新装载这个文件系统。

5.恢复任何被破坏的文件
为了修正文件系统的错误，fsck会删除一个或者多个文件，观察fsck输出的”REMOVE"的信息，确保从磁带上恢复受影响的文件。

fsck会重新链接孤儿文件。

如果和看到任何重链接的信息，检查文件系统的lost+found目录。

下一节会讨论lost+found目录的细节。

检查lost+found
存在每一个文件系统中
fsck会拷贝孤儿文件到这些目录下去。

在每一次fsck完成之后应该检查这个文件
在每一个文件系统的root目录下，都应该有一个lost+found目录。

这个目录是newfs命令创建的。

在使用fsck 命令检查这个文件系统的时候，你应该检查这个目录是否存在，如果不存在，你可以通过/usr/sbin/mklost_found 命令来重新创建这个目录。

fsck将所有检查有问题的文件放在lost+found目录下。

在fsck完成之后，你应该检查这个目录的内容。

这个目录中的文件可以被移动回它们原始的目录。

文件名是以inode号来命名，所以判断文件实际上是属于哪个文件十分困难。

但是你应该试图找到文件的属主。

对这个文件运行file命令。

如果这个文件包含文本，查看文本的内容来确定文件的属主。

如果文件包含可执行代码，你可检查是否有SCCS确认字符串，如果有，使用what命令可以列出SCCS信息。

如果这个文件没有SCCS字符串，你可以使用strings命令来查看文件的字符。

这些字符能帮助确认文件属主。

不要试图通过执行在lost+found目录中的可执行文件来找出这个文件是什么文件，因为它可能就是是破坏这个磁盘的文件。

例子：
# cd /myfs2/lost+found
# ls -l \#1743
# file /#1743
# strings \#1743
# move \#1743 new_file_name。