题目

某文件系统采用索引节点存放文件的属性和地址信息，簇大小为 4 KB。每个文件索引节点占 64 B，有 11 个地址项：

• 直接地址项 8 个
• 一级、二级、三级间接地址项各 1 个
• 每个地址项长度 4 B

请回答下列问题：

(1) 该文件系统能支持的最大文件长度是多少？（给出计算表达式即可）

(2) 文件系统用 1 M（）个簇存放文件索引节点，用 512 M 个簇存放文件数据。若一个图像文件的大小为 5600 B，则该文件系统最多能存放多少个这样的图像文件？

(3) 若文件 F1 的大小为 6 KB、文件 F2 的大小为 40 KB，则该文件系统获取 F1 和 F2 最后一个簇的簇号所需的时间是否相同？为什么？

解析

准备：每个间接块能管多少个簇？

簇大小 4 KB = 4096 B，每个地址项 4 B，所以每个间接块能装：

各级间接地址能管理的簇数累计：

级别	单项管的簇数	本级共管簇数	累计可达
直接（8 个）	1	8	8
一级间接（1 个）	1024	1024	8 + 1024 = 1032
二级间接（1 个）
三级间接（1 个）

（1）最大文件长度

最大文件 = 所有 4 级地址项全部用满时的总簇数 × 4 KB：

按级别拆开看：

来源	簇数 × 4 KB	大小
直接地址项
一级间接
二级间接
三级间接
合计

编者注（数量级直觉）：

• 三级间接独占 4 TB，远远压倒其它三级合起来才几 GB——这正是为什么大型文件系统都设计三级间接（甚至更高）。
• 反过来，小文件（绝大多数现实文件）只用直接地址项即可——8 × 4 KB = 32 KB，覆盖了大部分配置文件、源代码等典型场景。这种"小文件零间接、大文件多级间接"的设计，就是 Unix 索引节点的核心智慧。

（2）能存多少个 5600 B 的图像文件？

思路：求两个上限的较小值

约束 1：inode 数量上限

inode 区共 1 M 个簇 × 4 KB / 64 B/inode：

每个文件至少占 1 个 inode → inode 数量约束最多 64 M 个文件。

约束 2：数据空间上限

每个 5600 B 的图像文件需要几个簇？ 个簇（5600 > 4096，第二簇只装 5600−4096 = 1504 B 数据）。

数据区 512 M 簇 ÷ 2 簇/文件 = 256 M 个文件

取较小者：。

编者注（两个常考瓶颈）：

• 文件数 =
• 本题瓶颈在 inode 数——比数据空间约束严 4 倍，所以 inode 满了数据区还剩 75%。
• 现实中如果一台 NAS 装满了大量小文件，就可能 "df 看着空间没满，touch 却报 No space left on device" —— 这是 inode 用光了。本题的 64 M vs 256 M 数字差正是这种现象的"考场版"。

（3）F1 与 F2 的最后簇号访问时间是否相同？

答：不同。

F1：6 KB

文件大小 = 6 KB，需要 个簇。但文件大小和用了几个簇还要看跟 8 × 4 KB = 32 KB 的关系：

→ F1 的所有簇都在 inode 的直接地址项里。读最后一个簇的簇号 = 直接读 inode 的对应字段，0 次磁盘 I/O（只查 inode）。

F2：40 KB

→ F2 的最后一个簇落在一级间接的范围内。要拿到簇号必须：

1. 从 inode 读出"一级间接表"的指针 → 读那个间接表块 → 1 次磁盘 I/O
2. 在间接表里查到最后簇号

对比

文件	簇号在哪	读簇号需要的额外 I/O
F1（6 KB）	inode 的直接地址项	0 次
F2（40 KB）	一级间接表	1 次

→ 时间不同，F2 比 F1 多 1 次磁盘读。

编者注（核心规律）：

文件大小区间	簇号位置	额外 I/O
	直接地址	0
~ 一级上限（）	一级间接	1
一级 ~ 二级上限（）	二级间接	2
二级 ~ 三级上限（）	三级间接	3

文件越大，访问任意簇所需的间接寻址次数越多。这也是为什么实际系统会缓存常用 inode 和间接块——避免反复读盘。