HP Unix 修复文件系统

系统管理员的基本职责之一就是保护用户数据。

因为HP-UX使用的数据存储结构是文件系统，所以定期检查文件系统存储环境可能出现的为你是非常重要的。

文件系统的完整性是不容被破坏的，系统管理员可以做很多工作来维护文件系统的完整性。

1.

文件系统的修改过程

当文件系统被挂起后，它的超级块被拷贝到RAM中，文件系统的标志被设置为“dirty”，所有对超级块的修改首先在核心拷贝中进行。当一个sync系统调用或命令被执行时，在磁盘上的拷贝被修改。当一个文件系统被卸载时，所有在内核中的结构被重新写入磁盘，文件系统的标志被设置为“clean”。

所有对结构数据的修改首先在内存中进行拷贝，然后写入磁盘。

有一些结构数据修改立刻被写入磁盘，另一些则当sync执行时被写入磁盘。

大多数的文件系统事务会涉及到几个结构数据的修改，例如：

rm myfile命令将产生如下的改变：

（1）myfile的目录条目被删除

（2）描述myfile的I节点被释放

（3）跟踪空闲数据块和空闲I节点的对照表必须被修改

（4）在超级块里的空闲数据块和I节点数字必须被修改

不幸的是，所有结构数据在磁盘上并不是连续存储的，所以完成这个事务处理可能需要多次写入过程。

如果系统在中途崩溃，就会造成结构数据不一致。

例如myfile目录被删除，但I节点并没有释放，就会造成I节点的连接数字为1，却没有目录指向它。

2.

缓冲存储区

当需要写入用户数据时，真正的写入操作并不立即执行。
首先数据被拷贝到内存中被称为缓冲存储区的缓冲区内，这个操作比系统执行真正的磁盘写入操作要快一些。数据和I节点信息通常在缓冲存储区满了或系统需要清除一些缓冲空间时才被写入磁盘。
如果系统关闭时没有将缓冲区数据写入磁盘，文件系统就会崩溃。
如果你怀疑文件系统崩溃，应该禁止继续在文件系统上工作。

拥有缓冲区的的优点和益处有：

使用缓冲存储区使对磁盘的访问统一，因为内核不必知道I/O的情况。内核只是将缓冲内容写入到磁盘，而不是部分缓冲或实际使用的数字，所以从磁盘I/O角度来看，系统的设计就简单了。

通过使用缓冲机制，程序容易被一直到其他UNIX系统，在不同的UNIX主机上的磁盘I/O可能不同，但程序不需要知道这些。它们简单的写入到缓冲区中，不用担心磁盘时怎么样安装的。

安装缓冲存储区减轻了系统负载，增加了整个系统的性能，加速了响应时间，或者说系统运行的速度变快了。

缓冲区内的数据文件重复使用也可以加速系统运行。

3.

JFS意图日志

在JFS日志中，所有对结构数据写该需要完成事务处理，都被组织到一起。修改首先对内核中的结构数据进行。在内存中创建一条意图日志事务记录，然后再写入到JFS意图日志中，一个事务只有在意图日志记录被写入后才提交，防止了一个事务被部分完成的发生。

4.

刷新缓冲存储区

当数据被写入磁盘前，首先被写入内核中的缓冲区。从缓冲区到磁盘的物理写入过程发生在以下情况：
系统需要使用缓冲区进行其他操作
块的最后一个字节被修改
文件系统被卸载
sync命令被执行
系统被关闭或重新启动

syncer通常在系统启动时从/sbin/init.d/syncer脚本开始，负责自动定期刷新缓冲存储区。
不能直接执行syncer命令，需要在系统启动时通过脚本执行。

sync执行系统调用，将所有没有被写入磁盘的缓冲，包括被修改过的超级块，被修改过的I节点和被延迟的块I/O写入磁盘中，保证了在执行的重要操作。
如系统关闭时，将所有对文件的正确修改写入磁盘。
你可以在任何时候手工执行sync命令，虽然sync被syncer守护进程定期执行。

5.

fsck命令

当HP-UX系统非正常关闭时，文件系统的改变可能会丢失或不完整。
当系统崩溃或非正常关闭时，fsck将自动执行，检查文件系统结构的完整性，这个工具试图尝试修复所有确实不一致的数据。

fsck在非正常关闭系统后被自动执行，如果怀疑文件系统损坏，可以手工执行这个命令。

执行fsck需要下面几个步骤：
1.mount -v 确定文件系统被挂在哪里，还要注意哪些文件系统时HFS，哪些是JFS，执行修复时需要知道文件系统类型。
2.umount /dev/vg01/fs1
umount /dev/vg01/fs2
fsck需要在没有被使用的文件系统上执行，运行前需卸载文件系统。
3.fsck -F hfs /dev/vg01/rfs1
fsck -F vxfs /dev/vg01/rfs1
必须指定需要检查的文件系统类型，指定所在磁盘或者逻辑卷的字符设备文件

当在JFS文件系统上执行fsck时，fsck只是依靠意图日志，并完成所有被挂起的事务。
当fsck发现文件系统不一致时指出问题，并询问是否采取修复措施。
4.mount /dev/vg01/fs1
mount /dev/vg01/fs1
5.恢复所有被破坏的文件。
为了恢复被破坏的文件系统，fsck可能不得不删除掉一些文件。
fsck输出中的REMOVE信息，确保重磁带中恢复受影响的文件。
fsck输出RECONNECT信息，则应检查文件系统的lost+found目录。
fsck命令的一些选项：
-F 文件系统类型
-n 假设对fsck的所有问题回答No
-y 假设对fsck的所有问题回答yes
-b 告诉fsck去使用备用的超级块（仅适用于HFS）
-f 强制在被挂起的文件系统上执行fsck（仅适用于HFS）
-o full 强制fsck对文件系统的元数据进行全面检查而不是指重放意图日志（仅用于JFS）
-o nolog 阻止意图日志重放（仅用于JFS）

由于JFS文件系统的意图日志机制，JFS文件系统的数据结构不会被非正常关机破坏。
非正常关闭后，fsck只需要完成挂起的意图日志事务处理，将JFS置于稳定状态。
这一步称为意图日志重放。
需要几分钟甚至几小时来修复HFS，但只需要几秒钟内就能完成JFS日志重放。
可以通过-o full选项强制对JFS所有结构数据进行全面检查。

6.

检查Lost+found

每个文件系统在它的根目录下都有一个lost+found目录，由newfs建立。
在运行fsck前先检查这个目录是否存在，如果不存在，使用/usr/sbin/mklost+found命令创建。
fsck将所有有问题的文件和目录放到这个目录中。
完成修复后，应检查这个目录的内容，将这个目录中的文件放回到原来的目录。
被分配的文件名是I节点号，所以通过文件名判断文件来源几乎是不可能的。
但你可以试图去发现文件的所有者。
对这个文件进行file，判断文件类型。
如果文件包含文本，则查看内容来确定所有者。
如果文件包含可执行代码，则检查它是否包含SCCS标志字符串。如果有，what命令列出标识信息。
如果没有包含SCCS标识字符串，则用strings命令从文件中显示字符串，这些字符串将有助于确定所有者。
不要执行lost+found目录中的可执行文件，也许这是一个毁坏磁盘的文件。
cd /myfs1/lost+found
ll \#1743
file \#1743
strings \#1743
mv \1743 newfilename

http://moko39848381.blog.163.com/blog/static/139827331201032361315497/