4. inode 分配机制：文件系统创建时的 inode 预分配、动态 inode 分配策略、inode 位图管理

inode 是文件系统元数据的核心载体，其分配策略直接影响文件系统的创建速度、最大文件数上限以及碎片化程度。本章从工程实践出发，深入剖析 inode 预分配、动态分配与位图管理的底层机制。

4.1 文件系统创建时的 inode 预分配

在格式化阶段（如 mkfs.ext4），文件系统会根据块大小、卷大小和用户指定的参数，预先计算并分配固定数量的 inode。这一过程称为 inode 预分配。

4.1.1 预分配的计算模型

预分配数量由 inode 密度（bytes-per-inode）决定。默认情况下，每 16384 字节（16 KB）分配一个 inode。计算公式如下：

预分配 inode 总数 = 卷总字节数 / bytes-per-inode

例如，一个 1 TB 的卷，默认 bytes-per-inode 为 16384：

1 TB = 1,099,511,627,776 字节
预分配 inode 数 = 1,099,511,627,776 / 16384 ≈ 67,108,864 个

4.1.2 预分配参数对比

4.1.3 预分配阶段的磁盘布局

预分配完成后，inode 表在磁盘上以连续块组（block group）的形式分布。每个块组包含固定数量的 inode，并维护独立的 inode 位图。

4.2 动态 inode 分配策略

当文件系统运行时，创建新文件需要从预分配的 inode 池中分配一个空闲 inode。动态分配策略决定了分配效率与碎片化程度。

4.2.1 分配流程

1. 定位块组： 根据当前目录所在块组或全局分配策略，选择一个目标块组。
2. 扫描 inode 位图： 在位图中查找第一个值为 0 的 bit（空闲 inode）。
3. 标记占用： 将对应 bit 置为 1，并更新 inode 表。
4. 返回 inode 编号： 将 inode 号返回给 VFS 层，用于后续文件操作。

4.2.2 分配策略对比

4.2.3 Orlov 分配器核心逻辑

Orlov 分配器在分配 inode 时，会评估以下因素：

• 目录深度： 顶层目录（如 /home）倾向于分散到不同块组。
• 块组空闲率： 优先选择 inode 与数据块空闲率均较高的块组。
• 父目录位置： 子目录尽量与父目录同块组，减少跨组访问。

4.3 inode 位图管理

inode 位图是文件系统元数据中最核心的位图之一，用于跟踪每个 inode 的分配状态（0=空闲，1=占用）。位图的管理效率直接影响文件创建与删除的性能。

4.3.1 位图存储结构

每个块组维护一个独立的 inode 位图，占用一个完整的数据块（通常为 4 KB）。位图中的每个 bit 对应一个 inode 编号。

块组大小 = 块大小 × 8 × 每个块组的块数
inode 位图大小 = 块大小（4 KB）= 32768 bits
每个块组最大 inode 数 = 32768 个

4.3.2 位图操作流程

4.3.3 位图缓存与一致性

Linux 内核通过 buffer cache 缓存 inode 位图块，减少磁盘 I/O。但缓存引入了一致性问题：

• 脏位图： 内存中的位图修改后未及时写回磁盘，系统崩溃可能导致位图不一致。
• 日志保护： ext4 的日志（jbd2）会记录位图修改事务，崩溃恢复时回放日志保证一致性。
• 校验和： ext4 在块组描述符中存储位图块的校验和，用于检测静默数据损坏。

4.4 工程故障排查清单

当遇到 inode 相关故障时，按以下步骤排查：

1. 检查 inode 使用率： df -i 查看各文件系统 inode 使用百分比。
2. 定位 inode 耗尽块组： dumpe2fs -h /dev/sdX | grep -i "inode count" 查看块组分布。
3. 分析分配策略： 检查内核版本与挂载参数，确认是否启用 Orlov 分配器。
4. 检查位图一致性： e2fsck -fn /dev/sdX 扫描位图与 inode 表是否匹配。
5. 评估碎片化程度： fsck.ext4 -fvc /dev/sdX 输出块组空闲率分布。