日志文件系统ext4/xfs

可视化演示

展示ext4/xfs日志文件系统中数据写入经日志记录、事务提交、检查点到磁盘的完整流程，及三种日志模式的安全性与性能对比。

崩溃一致性困境

设想一间客栈掌柜用一本总账记录客人的入住，某晚停电时他正登记一位新客人，名字写了一半。来电后账本上半页是新的、下半页是旧的，客人到底住没住？这在文件系统里就是崩溃一致性问题：系统在任意时刻掉电，正在写入的数据块和描述文件大小、位置的元数据可能停留在不一致状态。

没有日志的文件系统只能等下次开机时做全盘检查（fsck），像账房先生把每一页账从头核对一遍。磁盘越大，核对时间越长，可能从几分钟拖到几小时，这对现代服务器来说不可接受。于是，我们需要一种“白板”来记录未完成的改动。

fsck的开销与磁盘上的块数量密切相关：假设磁盘有 N 个块，fsck需要扫描并验证每个块的归属与一致性。

所以，没有白板的掌柜只好停机数小时重新对账，这就是旧文件系统在崩溃面前的最大痛点。

预写日志机制

聪明的掌柜在柜台放一块小白板，每次改账前先在白板上写下“某日改某页”，再动笔誊账。万一停电，来电后照着白板把没写完的补上即可。这就是预写日志（Write-Ahead Logging，WAL）的核心：改动正式落盘前，先把意图记在日志里。

文件系统将“即将进行的修改”作为一个事务，先写入独立的日志区，随后才覆盖数据区和元数据区。这个顺序是崩溃一致性的基石：只要日志提交了，即使数据没写完，恢复时也能重放日志把改动补完；如果日志没提交，数据写一半也会被忽略，不会污染正式数据。

事务提交必须满足“日志先于数据”的顺序，用偏序关系表达：

白板上的记录是“证据”，账本上的改动是“事实”。证据先于事实，即使中途断电，掌柜也有据可依。

ext4日志设计

ext4老板把白板管理得井井有条，但记录方式有三种激进程度：有人只写标题，有人写清明细，最谨慎的连客人长相也记。对应ext4的三种日志模式：writeback、ordered、journal。

• writeback：只记录元数据变更，不保证数据先于元数据落盘，性能最好但崩溃后可能出现数据内容与元数据不一致。

• ordered（默认）：只记录元数据，但强制数据块先落盘、再提交元数据日志，兼顾性能与安全。

• journal：数据和元数据全部写进日志，恢复能力最强，但写入放大和IO开销最大。

三种模式的一致性强度依次递增，目标偏序关系为：

客栈平常订单用ordered，贵重物品用journal，而writeback像只记“收了钱”却不写“给了谁”，快却容易出岔子。选哪种，取决于店里对丢账的容忍度。

ext4空间分配

为了少跑几趟，掌柜把客人的点菜攒成一摞再一次性交给后厨，后厨烧菜更连贯。ext4的延迟分配也是类似：写操作先在内存中积攒，凑成一段连续空间再统一落盘，从而降低磁盘碎片、提升吞吐。

传统文件系统每次写入立即分配块，容易造成碎片。ext4把写入延迟到真正提交时分配，并尽力分配连续块。对大量小块写，还采用多块分配一次申请多个块；大文件则以extent描述连续块范围，一个起点加一个长度就能表示成百上千块，大幅缩减元数据量。

一个extent可表示为“逻辑块 B_l 映射到物理块 B_p，长度为 L”：

这就像给常客发一张“连住三晚四号房”的卡片，不必每晚重新登记，省事省纸，也让客栈的空间利用更规整。

xfs结构解析

另一位掌柜用了全新的记账柜：每位客人的信息做成索引卡，按B+树排列，找卡、插卡都极快。xfs就是这样的激进设计者，它用B+树管理extent，并在磁盘上划分多个分配组。

xfs将磁盘划分为多个分配组，每个组拥有独立的空闲空间索引，因此多个线程可以同时在不同组里分配空间，天然支持高并发。它还采用延迟日志技术，把日志先驻留内存、批量提交，减少磁盘同步次数。在大量文件并发写、超大文件顺序写等场景下，xfs的表现远比ext4从容。

B+树的查找复杂度与数据规模呈对数关系：设每个节点最多有 m 个分支，磁盘上extent总数为 N，则定位一个extent的时间为：

索引卡柜让掌柜在大量账目面前依然从容。xfs尤其适合大文件、大目录和许多进程同时写文件的场景，像春运期间的前台。

对比与选型

小客栈用ext4这样简单朴素的记账法够用；大客栈客流复杂，就需要xfs这种多柜台并行的大系统。选谁，本质看你的负载类型。

ext4与xfs的差异集中在两个维度：日志细节与空间分配。ext4默认ordered模式，日志位于文件系统内部，实现简单；xfs支持延迟日志，日志记录更精简，利于高并发。空间分配上，ext4的延迟分配和extent对中小文件友好；xfs的分配组+B+树对超大文件和海量文件并发更有利。

磁盘IO成本可以简化为寻道成本与传输成本之和。若一次操作有 n_s 次寻道、n_t 次传输，单次寻道时间为 T_seek、单次传输时间为 T_transfer，则总成本为：

掌柜选账本，不只看厚不厚，更看客人会不会排队、会不会频繁换房。普通业务服务器、开发机选ext4；云存储、大数据分析、高并发写入场景选xfs，方为明智。

AI 应用场景

Python 演示

class WalStorage:    def __init__(self, size):        self.data = [0] * size   # 模拟数据区        self.log = []            # 模拟日志区     def put(self, key, value, crash=False):        self.log.append((key, value))   # 先写日志        if crash:            raise IOError('power lost after journal append')        self.data[key] = value          # 日志提交后才写数据     def recover(self):        for key, value in self.log:     # 重放日志            self.data[key] = value        self.log.clear() def main():    store = WalStorage(4)    store.put(0, 10)    try:        store.put(1, 20, crash=True)    except IOError as e:        print('模拟崩溃:', e)    print('恢复前 data:', store.data, ' 日志条目:', len(store.log))    store.recover()    print('恢复后 data:', store.data) if __name__ == '__main__':    main()

1. self.log.append((key, value))每一次写操作都先追加到日志，体现WAL的“日志先行”。
2. raise IOError('power lost...')在日志已写、数据未写时抛出异常，模拟断电崩溃点。
3. self.data[key] = value只有日志成功且未崩溃时，数据才真正落盘。
4. for key, value in self.log恢复时遍历日志，把未完成的写操作重新应用。
5. store.recover()调用恢复逻辑，最终数据区与日志保持一致。

常见误区

面试题