文件系统重做日志与提交边界

日志提交与home安装是两个时刻。提交保证已经有一份足够完整的重做依据，home安装把它搬到正常读取位置。提交之后哪怕只搬完一个块便掉电，恢复仍可把其他块补齐。

“日志清掉了”也有稳定边界。若只在内存中清头便重用payload，掉电后旧提交头仍可能指向新一轮内容；旧事务的身份不能和新事务的字节混在一起。

新建文件的四个块必须同一代 ​

初始目录d没有new，inode43未分配，数据块70空闲。事务T建立new→43，内容NEW，修改四个home块：70的数据、80的块位图、81的inode记录、82的目录记录。它们的after-image分别放入日志90…93，提交头位于94。

恢复不变量不是“设备上时时四块一起变”，而是每个允许崩溃点经恢复后，四个相关home共同等于完整旧状态或已提交新状态。中间home可以混合，只要稳定日志足以完成已提交事务。

三个看似省事的错误 ​

省略payload的flush而先提交头：设备可能先稳定COMMIT，payload仍旧；恢复得到错误内容。省略home的flush而清头：恢复见EMPTY，却只有部分home新，没有可用日志补齐。省略清头的flush而复用payload：旧COMMIT可能配上新payload，恢复一个从未提交的混合事务。

这些错误分别破坏“提交证据完整”“清除前结果已安装”“复用前旧身份已失效”。一次顺序运行恰好没遇到乱序不能证明它们安全。

证明分两种稳定头。H为空时，未提交事务不曾写home；或者先前home已全部稳定，因此有完整状态。H为COMMIT时，先行flush保证其所有payload稳定，恢复写完整after-image得到新状态。after-image重复写幂等，所以恢复过程中再次掉电仍可从同一日志继续；只有home全部稳定后才可能持久清头。归纳覆盖任意有限次恢复中再崩溃。

对n个不同home块，本协议通常需n次payload写、1次提交头写、n次home写、1次清头写，总2n+2次块写及4次flush；n=4即10次块写。可用组提交、合并同块更新等优化，但要重证顺序。这里不把延迟home写的性能收益说成没有额外写放大。

真实xv6 rev5 §10.5–10.6有日志吸收和分块write；较大的write可能跨多个事务，不能由“有日志”推出整次write原子。ext4也有metadata-only、ordered及data-journal等模式；本页特意日志化这4块完整内容，不能把其数据原子性直接赋给默认ext4模式。底层设备flush契约是本模型另加的保证，不从教材中的同步函数名自动推出。