文件存储空间管理：从位示图、索引分配到inode排障

1. 文件存储空间的管理到底在管什么

很多人学操作系统，进程调度、内存分页、死锁检测一路啃下来都觉得还能接受，唯独翻到文件存储空间的管理这一章，脑子里就剩下一堆位示图、索引块、成组链接的图，看得懂每个字，串不起来一件事：这些东西究竟在解决什么问题。我用一句话概括——它要解决的是"一块容量有限的物理盘，怎么让无数个大小不一的文件，既能塞得进去、又能快速找到、还能在删除之后把空间干净地还回来"。

这件事的难点不在于"存"，而在于记录。你往盘上写1MB数据，其实是写进了256个4KB的块里，盘本身只知道"第10394号块被写了"，它完全不知道这256个块属于同一个文件、这个文件叫什么名字、下一个块在哪。把这些散落的块重新组织成"一个文件"的，就是文件系统；而记录"哪些块被占了、哪些块空着"的，就是文件存储空间的管理。所以这门学问本质上是元数据的管理学。

适合谁看？如果你是准备操作系统考试的学生，这里的计算题、方案对比能直接对上考点；如果你是运维或后端开发，磁盘告警、inode耗尽、删了文件空间不释放这些线上问题，根子全在这一章；如果你只是好奇为什么格式化一块盘要选块大小、为什么小文件会把盘撑爆，那更该往下看——这些现象没有一个是玄学。

1.1 先把三层概念对齐：扇区、块、文件

讲空间管理之前，必须把三个单位分清楚，这是后面所有讨论的地基。最底层是扇区，机械盘上通常是512字节，现在很多盘是4KB，它是硬件读写的最小单位，盘自己只认这个。往上一层是块，也叫簇、逻辑块，是文件系统自己定义的单位，常见4KB，也可以格式化成1KB、2KB、8KB甚至更大。

块不是硬件的概念，是文件系统为了管理方便人为划分出来的。为什么不直接用扇区当单位？因为一块1TB的盘如果按512字节切，块数是2的31次方，超过21亿个。记录这么多块的状态，元数据本身就要吃掉几百MB，而且寻址一个块需要31位，指针都得用4字节以上，纯属自找麻烦。把4KB合成一个块，块数直接降到2.68亿，元数据压力立刻小一个数量级。

这里有个关键结论，后面会反复用到：块越大，块数越少，元数据越省，寻址越快；但块越大，每个文件的最后一个块浪费得越多。一个10字节的配置文件，占一个4KB块，实际浪费4094字节，这叫内部碎片。平均下来每个文件浪费半个块，一个存了100万个小文件的目录，光碎片就能吃掉2GB。

1.2 三个必须回答的问题：分配、回收、定位

任何一套文件存储空间的管理方案，说到底都在回答三个问题，缺一不可。

第一，新文件来了，给它哪些块？这叫分配策略。是找一段连续的块给它，还是东一块西一块拼起来，还是干脆用索引表串起来，三种答案对应三种完全不同的性能特征。

第二，文件删了，怎么把这些块还回去？这叫回收与空闲空间管理。盘上必须有一份"账本"，记录每个块是占用还是空闲。账本的形式有四种：空闲表、空闲链表、位示图、成组链接。这四种方案的差别，本质上是"查得快"和"占内存少"之间的取舍。

第三，读第N个字节的时候，怎么找到对应的块？这叫寻址。这是三者中影响最大的一个——它直接决定了随机读和顺序读的速度差距，也决定了一个文件最大能有多大。

三个问题串起来才对完整：分配决定文件在盘上的形状，空闲管理决定能不能找到空位，寻址决定能不能快速找到数据。很多人学的时候把它们当成三块独立知识点背，考试能过，但遇到实际问题就傻眼了。比如"为什么我的盘明明还有空间却写不进去"，答案在空闲管理；"为什么读一个大文件的开头和结尾速度差这么多"，答案在寻址。

1.3 为什么这件事比想象中难

难在三个矛盾的叠加。

矛盾一：连续更快，但连续不可持续。如果一个文件的所有块在物理上挨着，磁头不用来回跑，顺序读几乎能跑满盘的理论带宽。但盘是反复增删的，用一段时间之后一定千疮百孔，这时候再来一个大文件，根本找不到足够长的连续空闲区。这就是外部碎片。想解决就得做紧凑，把所有已用块挤到一起——而这件事的代价是把整块盘的数据搬一遍，几个TB的盘能做，但没人愿意等。

矛盾二：元数据越细越好管，但越细越占地方。想精确知道每个块的状态，就一个块记一位，这是位示图的思路，够细了。但1TB盘按4KB切，位示图就是32MB，常驻内存还行，可要是有十几块盘呢？于是有了成组链接这种"把账本拆成组、只把当前组放内存"的折中方案。

矛盾三：文件大小差异巨大，一套策略覆盖不了。盘上同时躺着10字节的配置文件和10GB的镜像文件。前者需要小块省碎片，后者需要大块省元数据、提高吞吐。任何单一块大小都是在两者之间妥协，这也是为什么现代文件系统要引入extent、延迟分配、多块分配这些机制——它们想让"给大文件分配时用大粒度、给小文件分配时用小粒度"这件事同时成立。

理解了这三组矛盾，后面所有具体方案你都能自己推出来：任何一种设计，无非是选择了在哪个矛盾上让步。看方案的时候先问一句"它牺牲了什么"，比记它的实现细节有用得多。

2. 空闲空间怎么记账：四种主流方案与选型逻辑

空闲空间的账本，是这门课最像"数据结构应用"的部分。教材上列了四种，很多人背完就忘，因为不知道为什么要搞四种。其实只要抓住一个维度：账本放在哪、以什么形式组织，四者的演进脉络就清楚了。

2.1 空闲表与空闲链表：最直觉的两种做法

空闲表的思路和内存管理的分区分配一模一样：维护一张表，每一项记录一个连续空闲区的起始块号和块数。比如（起始块 100，长度 50）表示100到149这50个块都是空的。

分配时用首次适应、最佳适应之类的算法在表里找一块够大的。回收时麻烦一点，因为归还的空闲区可能正好和前后两个空闲区挨着，需要做合并——否则用不了多久表里就全是零碎片段，明明总空闲块数够，却找不到连续的。

空闲链表把每个空闲区做成一个链表节点，节点存在空闲块自己里面——前几个字节存"下一个空闲块的块号"和"本区长度"，剩下的是真正的空闲空间。这样不用额外开表，链头指针放在超级块里就行。

两种方案的优缺点高度一致：结构简单、找连续区方便，但只适合"连续分配"的文件系统，而且空闲区一多，遍历成本就上来了。空闲表查一次是O(n)，空闲链表也是O(n)，n是空闲区数量，碎片化严重时n可以到几万，这时候每次分配都要扫一遍，性能直接崩掉。

注意：空闲表和空闲链表不是"淘汰方案"，在连续分配的文件系统里它们仍然是唯一合理的选择。判断一个方案好不好，先看它配套的分配方式是什么，脱离上下文谈优劣没有意义。

还有个容易忽略的点：空闲链表把指针藏在空闲块里，意味着这些块在被分配出去之前是被写过的。如果盘做过全盘加密或者有数据残留要求，这个做法会带来额外麻烦，这也是现代文件系统普遍改用位示图或B树的原因之一。

2.2 位示图：一位一块的"座位表"

位示图是我个人认为最优雅的方案。用每一位表示一个块的状态，0空闲、1占用（或者反过来，看实现约定），所有位按顺序排成一个位串。

它的好处非常直接：

• 空间极省。1位管1块，1TB盘按4KB分块，共2^28个块，位示图2^28位=32MB。注意，不管块多大，位示图大小只跟块数有关，跟盘容量成正比但系数极小。
• 查找空闲块极快。要找一个空块，就是找一个值为0的位，按机器字扫，一个64位字一次就能判断64个块，内存带宽跑满的情况下速度快得离谱。
• 分配回收都是位运算。置1、清0，常数时间，不会产生任何碎片结构，也不需要合并。

代价是什么？它只能告诉你"这个块空着"，不能告诉你"这里有一大片连续空闲"。所以位示图天然适配"离散分配"的文件系统——反正不需要连续，能找到一个空块就行。真要做连续分配，还得额外扫一段看看连不连续。

位示图的大小计算是经典考题，我把它拆开讲清楚：

假设磁盘容量1TB，块大小4KB，求位示图占多少字节。 块数 = 1TB ÷ 4KB = 2^40 ÷ 2^12 = 2^28 = 268435456 块 位示图位数 = 块数 = 2^28 位 换算字节 = 2^28 ÷ 8 = 2^25 字节 = 32MB

再补一个常见变体：如果题目给了"位示图的字号为32位，求第i个字第j位对应的块号"，公式是块号 = 字号 × 32 + 位号（从0开始编号）。这个公式考频极高，务必记牢。若要从块号反推字位，就是字 = 块号 / 32，位 = 块号 % 32。

2.3 成组链接：把大账本拆成小组

成组链接是这四种方案里最绕的一个，但它解决的痛点很真实：盘特别大、内存特别小。

想象一台老机器，内存只有几MB，挂了一块几GB的盘。位示图要几MB，全塞内存塞不下；空闲链表要遍历，太慢。怎么办？

成组链接的思路是：把所有空闲块分成若干组，每组固定100个（这个数字是经典设定，实际实现可变）。每一组的第一个块不存数据，而是存"这一组剩下99个空闲块的块号 + 下一组的块号"。所有组像链表一样串起来，超级块里只放当前组的全部信息（100个块号 + 指向下一组的指针）。

分配的时候，直接从超级块里的当前组取一个块号出来用，取完了再把下一组的内容读进超级块，成为新的当前组。回收的时候反过来，往当前组里塞，塞满100个就把这100个块号写到一个新块里，让新块指向原来的当前组，自己成为新的当前组。

这个设计的精妙之处在于：任何时刻内存里只需要一个组的元数据，却能用O(1)的时间完成一次分配或回收。既不像位示图那样要常驻一整张大表，也不像链表那样要遍历。用生活化的比喻，它像一摞打包好的箱子，你手上永远只开着一个箱子，用完一箱再拆下一箱，不需要把整仓库的箱子都摊开。

提示：成组链接的经典设定是每组100个，其中99个存块号、1个存指向下一组的指针。考试里如果出现"每组100个空闲块号"，那是指连指针算在内的总数，具体看题干措辞，别想当然。

2.4 四种方案的选型对照

把四种方案摆在一起看，选型的逻辑就非常清楚了：

我个人在实际系统里最常打交道的其实是位示图的变体。比如很多日志型文件系统用一整棵B+树或者位图区来管理空闲块，本质还是"一位一块"或者"一个区间一位"，只是组织结构更复杂，能同时支持"找单个空块"和"找连续N个块"两种查询。

选择的时候我一般这么判断：先看分配方式是否要求连续，要求连续就只能在前两种里选；不要求连续就优先位示图，盘大到内存放不下再用成组链接。这个判断顺序别搞反了，很多人一上来比较速度，忽略了分配方式这个前提，比出来的结论是错的。

3. 文件块怎么落盘：连续、链接、索引三条路线

如果说空闲空间管理是"记账"，那分配方式就是"怎么花钱"。三条路线的差别，直接体现在随机读性能、最大文件大小、外部碎片这三个指标上，而且几乎没有哪条路线能在三项上全赢，所以现代文件系统基本都是混合体。

3.1 连续分配：性能天花板，可惜不实用

连续分配最简单粗暴：创建文件时，一次性给它分配一段足够长的连续块，目录项里只记两个数——起始块号和长度。

它的优点是压倒性的。读文件时，只要知道起点，后面全在物理上挨着，磁头几乎不用跳，顺序读速度能接近盘的物理极限。而且寻址极简单：逻辑块号N对应的物理块号 = 起始块号 + N，一次加法搞定，连索引表都不用查。随机读也不差，因为文件内部是连续的，算一下偏移就能直接定位。

问题也同样致命。外部碎片——盘用久了必然千疮百孔，一个100MB的文件要求连续空间，哪怕总空闲有500MB，只要没有一段连续的100MB，就分配不出去。解决要么做紧凑（搬数据，代价巨大），要么拒绝创建（用户直接懵）。

还有文件增长困难。文件创建时定死了长度，后面要追加内容，如果后面那块被别的文件占了，只能整体搬家，或者预留一大段空着——预留又浪费空间。

我个人对连续分配的定位是：它是"理论上的最优解"，用来当基准线衡量其他方案。真实系统里只有极少数场景会用它，比如一次性写入只读介质（光盘映像、固件包），因为这类场景里"文件不再变化"这个前提成立，连续分配的全部缺点都被规避了。

3.2 链接分配与FAT：用指针把散块串起来

链接分配把连续的要求彻底放弃：文件由一堆散落各处的块组成，每个块的开头留几个字节存"下一个块在哪"，最后一个块存一个结束标记。目录项里只记首块块号。

这样一来，外部碎片消失了——只要盘上还有一个空块，文件就能继续长。文件增长也变得极其自然，追加内容就是再挂一个块上去。

代价是随机访问彻底废掉。想读文件第1000个块，必须先读第1块拿到第2块的地址，再读第2块……一路链下去，1000次磁盘I/O。这个方案只适合纯顺序读的场景，但凡需要随机跳转，性能就没法看。

FAT（文件分配表）是链接分配的主流改良。它把散落在各个块里的"下一个块号"全部抽出来，集中成一张表放在盘的固定区域，表项数等于总块数，第i项存的就是"块i的下一块号"。同时内存里缓存一份FAT，查找下一个块就变成了查内存数组，一次内存访问解决，不用再读盘。

但FAT的代价也很明显：表的大小与块数成正比，必须常驻或频繁访问内存。以FAT32为例，每个表项4字节，最多支持2^28个簇，表最大就是2^28 × 4B = 1GB。一块32GB的盘按4KB分簇有800多万个簇，FAT表约32MB，内存里放得下，但盘再大就吃力了。

这里有个很多人踩过的坑，值得单独说：FAT32单文件最大4GB减1字节。原因不是盘不够，而是目录项里记录文件大小的字段只有32位，最大能表示2^32-1字节。这个限制和块大小、盘容量都无关，纯粹是元数据字段宽度的问题。很多老设备要求U盘格式化成FAT32，拷一个5GB的镜像进去直接报"文件过大"，根子就在这。

3.3 索引分配与容量计算：把"地址簿"独立出来

索引分配的思路是：给每个文件配一张索引块，这个块不存数据，专存该文件所有数据块的块号。目录项里只记索引块的块号。

读文件第N块？直接查索引块第N项，一次I/O定位，随机访问能力和连续分配一个级别，同时保留了链接分配的灵活性——数据块可以散落在任何地方。这是三条路线里综合最优的，也是主流文件系统的基础思路。

问题在于索引块本身也是块，也要占空间。一个4KB的索引块，每个块号4字节，只能存1024个块号，对应1024×4KB=4MB的数据。文件超过4MB怎么办？上多级索引。

经典的多级索引结构（教材上的UNIX风格）是这样的：索引节点里放10个直接块号 + 1个一级间接 + 1个二级间接 + 1个三级间接。直接块号直接指向数据块；一级间接指向一个索引块，索引块里的每项指向数据块；二级间接指向"索引块的索引块"，以此类推。

这套结构能支持的最大文件是经典计算题，我把完整推演写出来：

设块大小4KB，每个块号占4字节，则一个索引块能存 4KB ÷ 4B = 1024 个块号。

• 10个直接块：10 × 4KB = 40KB
• 一级间接：1024 × 4KB = 4MB
• 二级间接：1024² × 4KB = 1048576 × 4KB = 4GB
• 三级间接：1024³ × 4KB = 1073741824 × 4KB = 4TB
• 合计约 4TB + 4GB + 4MB + 40KB

再补一个常考的反向题：读取文件偏移量为offset的字节，需要几次磁盘访问？步骤是：先算逻辑块号 = offset ÷ 块大小；再判断落在直接区、一级还是二级；然后按层级读索引块。比如偏移量落在二级间接区，就要读"索引节点（若不在内存）→ 二级索引块 → 一级索引块 → 数据块"，共4次。

这个结构的妙处在于对文件大小的分布做了合理的赌注：绝大多数文件很小，10个直接块能覆盖40KB，一次索引都不用查；中等文件走一级间接，成本一次；只有极少数超大文件才会走到三级。分层设计让"常见情况的成本最低"，这几乎是所有系统设计的通用套路。

3.4 extent：现代文件系统的折中之道

纯索引分配的元数据开销在大文件上很难看。一个10GB的文件，按4KB块算有260多万个块，每个块号4字节，光索引就要10MB以上，而且这些索引块本身是分散的，管理它们的元数据又是新一层开销。

现代文件系统（比如常见的日志型文件系统）普遍改用extent（区段）：不再记录"每个块的块号"，而是记录"起始块号 + 连续块数"。一个extent项通常12字节左右，能描述连续上千个块。一个10GB的文件如果分配得比较连续，可能只需要几千个extent就描述完了。

这就是第1.3节说的"同时满足大文件和小文件"的具体实现。extent本质上是连续分配和索引分配的混合体：文件用索引树组织，但索引的叶子节点描述的是连续区间而不是单个块。文件碎片少的时候，元数据极少，性能接近连续分配；碎片多的时候，自动退化成更多、更小的extent，灵活性还在。

看到这张表就知道，为什么教材要花一整章讲这块——没有银弹，只有取舍。你在做任何一个存储相关的技术选型时，问的第一个问题都该是"我的数据是大文件为主还是小文件为主"，答案不同，最优方案完全不同。

4. 动手：从格式化参数到可复现的模拟程序

理论讲完，落到能动手的部分。这部分是我认为最能拉开理解差距的：很多人能背出块大小和内部碎片的关系，但真让他去定mkfs的参数，就完全没数了。

4.1 块大小与inode密度：两个必须算的参数

块大小的选择逻辑很清晰：小文件为主选小块，大文件和高吞吐场景选大块。

具体怎么估算？假设你的场景存的是日志切片，平均每个文件8KB。块大小4KB时，每个文件正好2块，无浪费。块大小64KB时，每个文件占1块，浪费56KB，浪费率87.5%，100万个文件白白吃掉56GB。反过来，如果你的场景是大视频文件，平均每个2GB，块大小4KB时要50万个块，元数据开销巨大且IO次数多；用1MB的块，只需2048个块，元数据可以忽略，顺序读写效率也高。

我的经验法则是：统计一下你目录里文件的平均大小和大小分布，块大小取平均大小的1/4到1之间。如果分布是双峰（大量1KB配置文件 + 少量GB级数据），那就得接受折中，选4KB或8KB，靠文件系统的extent和小文件优化来兜大文件。

inode密度是很多人完全没概念、但会直接导致事故的参数。ext4格式化的默认值是每16KB空间分配一个inode（bytes-per-inode = 16384）。也就是说，一块1TB的盘，默认大约只有6700万个inode。

这个数字听起来很多，但如果你的业务是存大量小文件——比如邮件队列、缓存片段、会话文件，平均每个文件只有几百字节——那么空间还远远没用完，inode就先耗尽了，这时候创建新文件会直接报No space left on device。这个错误信息极具误导性，因为磁盘明明还有大把空间。

解决办法是格式化时用-i指定更小的bytes-per-inode，或者用-N直接指定inode总数：

# 每4KB给一个inode，适合海量小文件场景 mkfs.ext4 -i 4096 /dev/sdX # 或者直接指定inode数量（注意：inode一旦创建无法增加） mkfs.ext4 -N 200000000 /dev/sdX

注意：inode数量在格式化时就定死了，后期无法扩容（只能重建文件系统或另挂一块盘）。所以定这个参数要往前看三年，宁可多给，因为inode本身也占空间——每个inode约256字节，2亿个inode就是51GB，给太多同样浪费。这个权衡没有标准答案，只能按业务实际情况算。

4.2 观察工具链：看清楚空间到底被谁吃了

光会算不够，还得会看。我常用的几个观察手段，按排查顺序排：

第一层，看整体。df -h看挂载点的总容量、已用、可用；df -i看inode使用率。这两个必须一起看，很多人只看前者，然后在"磁盘没满却写不进去"上卡半天。

df -h df -i

第二层，看目录占用。du -sh *逐个子目录统计，配sort -rh排序最快定位大户。但要注意，du统计的是实际占用的块数，不是文件的逻辑大小，这两个数字在某些情况下差得很远（后面5.3节细说）。

du -sh /* 2>/dev/null | sort -rh | head -20

第三层，看单个文件。stat能一次性拿到文件大小、占用块数、inode号、块数，是定位问题最锋利的工具。

stat somefile.log # 重点关注： # Size: 逻辑大小（字节） # Blocks: 实际占用的512字节块数，乘以512才是真实占用

第四层，看文件系统内部。这一步就到元数据层面了，debugfs可以看超级块参数、inode使用明细、块组的空闲情况。新手别乱改，只读查询是安全的。

# 只读方式进入，查看文件系统参数 debugfs -R "stats" /dev/sdX # 查看某个inode的详细信息（包括它用了哪些块） debugfs -R "stat <12345>" /dev/sdX

这几个工具用熟了，磁盘问题的定位速度会有一个质变。我最常听到的抱怨是"找了半天不知道空间去哪了"，八成是因为只用了du，没做du和df的交叉验证。

4.3 用Python写一个位示图管理模拟

理论要落地，最直接的办法是自己把位示图实现一遍。下面这段代码我写过好几个版本，这个是最精简但能完整演示分配、回收、统计的：

class BitmapAllocator: def __init__(self, total_blocks): self.total = total_blocks # 每个字节存8个块的状态，初始全0（空闲） self.bits = bytearray((total_blocks + 7) // 8) def _get(self, blk): return (self.bits[blk >> 3] >> (blk & 7)) & 1 def _set(self, blk, val): byte_idx, bit_idx = blk >> 3, blk & 7 if val: self.bits[byte_idx] |= (1 << bit_idx) else: self.bits[byte_idx] &= ~(1 << bit_idx) def allocate(self, count=1): """连续分配count个空闲块，返回起始块号，失败返回None""" found, start = 0, -1 for blk in range(self.total): if self._get(blk) == 0: if found == 0: start = blk found += 1 if found == count: for b in range(start, start + count): self._set(b, 1) return start else: found, start = 0, -1 return None def free(self, start, count): for b in range(start, start + count): self._set(b, 0) def free_count(self): return sum(1 for b in range(self.total) if self._get(b) == 0) # 演示：1TB盘，4KB块 alloc = BitmapAllocator(2**28) print(f"位示图占用: {len(alloc.bits) / 1024 / 1024:.1f} MB") s1 = alloc.allocate(100) s2 = alloc.allocate(50) print(f"分配两段: {s1}, {s2}") alloc.free(s1, 100) print(f"回收后空闲块数: {alloc.free_count()}")

跑一遍你会直观感受到两件事：位示图确实只占32MB，与1TB的总容量相比微不足道；allocate里的线性扫描在碎片严重时确实慢——这就是为什么真实系统会用位图分块、多级位图、或者B+树来加速"找连续N块"这个操作。

提示：上面这段代码的位序约定是"低位在前"（第0块在第一个字节的最低位），这是Linux内核风格。教材上常见的约定可能是"高位在前"，考试答题时按题目给的约定来，不要想当然。

5. 排查实录：五类"看起来满了"的场景

这一节是我认为全篇最有价值的部分。文件存储空间管理在书本上是结构图和计算题，在生产环境里它就是一个个No space left on device。下面这五类场景，覆盖了我见过的问题的绝大多数。

5.1 场景一：空间还剩一大半，却写不进任何文件

这是最经典的一个。现象是df -h显示使用率60%，但任何创建文件的操作都失败，报No space left on device。

根因：inode耗尽。每个文件（包括目录、符号链接）都要占一个inode，而inode数量在格式化时就定死了。如果目录里堆了几千万个几百字节的小文件，空间确实只用了一点，但inode已经见底。

确认方法：

df -i # 看 IUse% 是否接近 100%

处理思路：短期只能清理无用小文件（尤其是临时目录、缓存目录里的陈旧文件），或者把部分数据迁移到新挂载的盘上。长期方案是在规划阶段就按业务特性调整-i参数。这里没有"扩容inode"这种操作，只能重建文件系统或加盘，所以防范的价值远大于补救。

顺带一提，df -i这个命令我建议养成和df -h一起敲的习惯，成本几乎为零，能省掉大量排查时间。

5.2 场景二：删了几个大日志文件，空间没释放

现象：用rm删掉了一个几十GB的日志文件，du看到的目录大小确实降下来了，但df显示的可用空间一点没变。

根因：文件被删除但句柄仍被进程持有。在类UNIX系统里，rm只是把目录项里的名字去掉了，文件的引用计数减一。只要还有进程打开着这个文件（引用计数不为零），它的数据块就不会被回收。这时候文件在文件系统里是"无名但有实体"的状态，du按目录遍历，自然看不到它，而df统计的是块的真实占用，所以两边对不上。

确认方法：

lsof +L1 # 或者 lsof | grep deleted

会列出所有"已删除但仍被打开"的文件，以及占用它的进程PID。

处理思路：重启相关进程，或者让进程重新打开日志文件（很多服务支持SIGHUP触发日志轮转）。千万不要直接kill -9，尤其是在数据库或消息队列场景，强杀可能带来数据一致性问题。

注意：这个坑最常见的触发方式是"手动rm了一个正在被写入的日志文件"。正确的做法是用日志轮转工具（按大小/时间切分），或者先清空内容而不是删除文件：> /path/to/file.log。这个操作会把文件截断为0字节但不删除inode，正在写的进程不会出错，空间立刻释放。

5.3 场景三：文件大小和实际占用差了十万八千里

现象：ls -lh显示某个文件有100GB，但du -sh显示只占1GB。或者反过来，du统计出来的总量比df已用量还大。

根因一：稀疏文件。有些程序（数据库、虚拟机镜像、日志预分配）会创建一个逻辑上很大、但实际只写了少数块的文件。中间没写的部分不占任何物理块。ls看的是逻辑大小（apparent size），du看的是实际块数，两者天然不同。

确认方式：

ls -ls bigfile # 第一列是实际占用的块数（512B单位） du -h --apparent-size bigfile # 强行看逻辑大小 du -h bigfile # 看实际占用

根因二：硬链接重复计数。同一个文件被多个目录硬链接，du默认只算一次，但如果分目录统计再相加，就会重复计算，导致总和大于df。

根因三：挂载点覆盖。某个目录下原来是数据盘，后来被另一个挂载点覆盖了，du会穿过挂载点统计，而df是按文件系统统计的。用du -x限制在单一文件系统内可以避免。

这三种情况本质都是统计口径不一致。我处理这类问题的固定动作是：先用df拿到文件系统级的真实占用，再用du -x逐层往下钻，两边对不上的那一层就是问题所在。

5.4 场景四：预留块吃掉了5%的空间

现象：一块1TB的盘，格式化后df显示的可用容量比1TB少了近50GB。

根因：日志型文件系统默认会给root预留5%的空间（Reserved block count），目的是防止普通用户把盘写满导致系统服务无法写入关键文件、也无法做碎片整理。这个设计在系统盘上非常合理，但在纯数据盘上就是纯浪费。

处理思路：

# 查看当前预留比例 tune2fs -l /dev/sdX | grep -i reserved # 数据盘可以调低到1%甚至0（系统盘建议保持5%） tune2fs -m 1 /dev/sdX

这个操作是在线生效的，不需要卸载，也没有数据风险，属于低成本高收益的优化。我一般在新盘上线时就顺手设成1%，几TB的盘能多出几十GB可用空间。

5.5 常见问题速查表

这张表我建议截图存手机里，半夜被叫起来处理磁盘告警的时候，比翻文档快得多。

6. 几个容易踩的坑和个人经验

理论和方案讲完了，最后这部分是我这些年真正踩出来的东西，很多是文档里不会写、但会让人加班到凌晨的细节。

6.1 三个反直觉的坑

第一个坑：块大小不是越小越好。直觉上小块省碎片，但块太小会让元数据爆炸。一个10GB的文件按1KB分块是1000万个块，索引结构、位示图、块组管理全部膨胀，而且每次IO只能读1KB，吞吐上不去。真实系统里4KB几乎是下限，低于这个值基本是给自己找麻烦。

第二个坑：文件系统的"可用空间"不等于"能写进去的空间"。除了inode、预留块，还有日志区、元数据备份、块组描述符这些开销，一块盘的可用空间通常比标称容量少3%到8%。规划容量的时候按80%可用来算，比按100%算要靠谱得多。我见过太多项目按标称容量做容量规划，上线三个月就告急。

第三个坑：删除大量小文件本身就是一场性能灾难。删100万个文件，每个删除都要改目录项、改inode位图、改块位图、写日志，可能跑几个小时，期间IO被严重挤占。正确做法是把它们放在独立目录里，直接删除整个目录树，或者更激进一点——直接重建文件系统，比一个个删快几个数量级。

提示：如果确定某个目录下的数据可以整体丢弃，mkfs重建文件系统是最快的"删除"方式。当然前提是你非常确定没有其他数据在那个分区上，这个操作没有任何撤销余地。

6.2 我做容量规划时的三个习惯

习惯一：先统计文件大小分布，再定参数。不要凭感觉。跑一遍find /data -type f -printf "%s\n" | sort -n | awk '{a[NR]=$1} END{print "中位数:", a[int(NR/2)], "90分位:", a[int(NR*0.9)]}'，看一眼中位数和90分位，块大小和inode密度立刻就有数了。

习惯二：永远留出20%的余量。不是为了好看，而是因为文件系统在高使用率下性能会明显下降——碎片变多、连续区难找、元数据操作变慢。80%是很多文件系统的经验拐点。

习惯三：把"空间监控"和"inode监控"当成两个独立指标。大多数监控模板只配了磁盘使用率，漏了inode。等真正出问题的时候，告警没响，业务先挂。这两条指标我建议都配上，阈值分别设在85%。

6.3 这个知识点后续还能往哪延伸

文件存储空间管理往下走，有几个方向很值得深挖。一个是日志与一致性，为什么现代文件系统都要先写日志再改元数据，这背后是崩溃一致性的问题。另一个是写时复制，它把"分配"这件事从"就地修改"变成了"写新块再改指针"，代价是空间回收变得复杂（老块什么时候能真正释放）。还有一个是分布式存储里的空间管理，本质问题从"一块盘怎么分块"变成了"一堆盘怎么分片、怎么保证副本一致、怎么在节点故障时重建"。

这三个方向任何一个往深了走，都能撑起半年的学习量。但地基永远是这一章：块怎么分、空位怎么找、地址怎么记。这三件事想透了，上面盖多高都不会塌。