MIT 6.S081 文件系统的崩溃恢复

原创

已于 2025-10-02 20:39:32 修改 · 702 阅读

28 ·

CC 4.0 BY-SA版权

文章标签：

#MIT 6.S081 #操作系统内核 #文件系统崩溃恢复机制

于 2025-09-28 22:31:17 首次发布

崩溃恢复机制简述

文件系统的崩溃

由于操作系统在执行任务时不可避免的遇到突然断电、磁盘受损等突发情况导致操作系统的崩溃。但文件系统中的数据是永久存在的，如果不做任何的措施会导致文件系统中的数据存在不一致、不正确的状态，这种状态是危险的。

logging机制

对于文件系统的突然崩溃，我们在重启操作系统时需要对文件系统进行恢复，使其能够满足数据的一致性、正确性。最笨的方法就是遍历一遍文件系统所有的文件，包括但不限于inode节点的情况，bitmap块的情况，各个数据块的情况，查看目前信息是否相互匹配。但显而易见的是这种方法时间复杂度太高难以接受。

此时，数据库技术中借鉴的日志恢复技术可以解决这个问题（都是对于数据的一致性保证，这点在数据库和操作系统的目的是一致的）。总的可以分为以下四步：

首先你对文件系统做的任何操作都不直接操控文件系统进行修改，而是先写在日志中，当一些列操作（需要原子性质的操作，即这一系列操作要么同时发生要么都不发生）全部完成时，就将这些操作进行提交。提交之后，操作系统才真正的按照日志中的信息对文件系统进行修改，这一步叫做安装。最后当日志中的所有内容安装完毕时，清空日志内容。

这是正常运行时的操作，当操作系统重启时，对于文件系统而言，首先检查日志中有无提交的标识，若有则重新执行日志中的所有操作，也就是安装。若无提交标识则清空日志。

我们依次考虑崩溃发生的每个时期，看有无影响。首先若发生在写日志阶段或者写完日志未提交，这时重启以后由于没有提交标识，会忽略日志中的内容，对文件系统无影响（因为原本也没有对文件系统进行修改）；当发生在提交之后（提交可以理解未一个原子操作，因为他就是一个写下一个标识，在操作系统层面，向某个磁盘某个扇区写，可以看作原子操作，所以崩溃不会说发生在提交过程中，只会发生在提交前或者提交后）或正在安装，这时重启之后由于已经有提交标识，所以会将日志中的所有操作重新安装，由于这里只有写操作（这里只考虑写操作，其他的文件操作可以通过这些简单的基本操作组合而成或者需要更复杂的机制来保障），所以他是幂等的，也就是无论执行多少次结果相同，所以这里对所有日志操作重新安装是没问题的；最后发生在安装后，清理日志前，这个和上面同理。

可以发现，通过日志的操作可以使一系列文件操作具备原子性，要么全部发生要么全部不发生，这有效的保证了文件系统