前阵子处理一个压测环境故障应用一直往日志目录写东西突然报No space left on device可我df -h一看根分区明明还剩 40 多 G。排查了大半天最后df -i才发现是 inode 用完了——几百万个小文件把索引节点全占满了。那次故障之后我算是彻底明白了用 Linux 不懂 Ext 文件系统遇到这种事只能干瞪眼。这也是《系统性学习 Linux》系列的第六讲想聊透的话题Ext 文件系统到底怎么组织数据、为什么会有这些古怪的毛病、以及日常运维怎么跟它打交道。这篇内容不仅讲原理也会把我踩过的坑、常用的命令和排查思路一并理清楚。1. 从一次磁盘满的误报说起文件系统在管什么1.1 没有文件系统时磁盘是什么样很多人把磁盘格式化成 Ext4当成理所当然的操作却很少想一个问题磁盘本身能理解文件这个概念吗答案是彻底不能。一块裸盘在你的操作系统看来就是一个线性排列的扇区数组。以常见的 512 字节或 4K 逻辑扇区为例它只能提供我能在第 N 个扇区读/写若干字节这种能力。它不知道什么叫文件名不知道什么叫目录更不知道什么叫这个文件属于哪个用户。你可以把裸盘想象成一块巨大的空白黑板扇区就是黑板上的横线格子。文件系统则是你在这块黑板上画好的一套管理规则哪几格记录文件尺寸哪几格记录文件内容哪几格记录文件名和它的对应关系还要留出位置记录哪些格子已经被占用了。没有这套规则操作系统连把文件放到哪这种最基本的决策都做不了。1.2 文件系统必须回答的三个问题抛开各种花哨术语任何文件系统本质上都要回答三个问题文件放在哪内容是紧凑存在连续的格子还是分散在不同位置记录这些位置用什么数据结构怎么知道一个文件是谁文件名、权限、大小、时间戳这些元数据存在哪哪些空间是可用的需要一个机制快速知道哪些格子空闲、哪些被占否则每次写入都要全盘扫描。这三个问题Ext2/Ext3/Ext4 各用了一套逐渐演进的方案来回答。我理解文件系统通常也从这三条线去对照比死记硬背结构图有效率得多。下文的布线和 inode 全是从这三个问题派生出来的。2. Ext 家族演进每个版本都是为了填一个坑2.1 Ext2零日志时代的可靠基础先说背景。Linux 早期用的是 Minix 文件系统它太简陋了——文件名最长 14 字节最大分区 64MB这在 90 年代初就已经不够看。1992 年 Rémy Card 设计了 ExtExtended File System1993 年就有了 Ext2。Ext2 的核心设计奠定了整个家族的基础把磁盘分成块组Block Group、用 inode 表管理文件元数据、用位图Bitmap管理块和 inode 的使用状态。这些概念直到 Ext4 也没变。但它有一个致命短板没有日志Journal。写入数据时元数据和数据内容是分多次落盘的一旦突然断电或内核崩溃磁盘上就会留下元数据改了但数据没写完或反过来数据写了但元数据没跟上的中间状态。恢复只能靠启动时跑fsck.ext2全盘扫描文件越多检查越久。生产环境几 TB 的盘跑一次完整 fsck 那个滋味相信老运维都懂。2.2 Ext3日志机制带来的崩溃安全所以 Ext3 相比 Ext2核心改进就一句话在原有结构上叠加了一个日志Journal让文件系统具备崩溃一致性。日志的工作原理我习惯用记流水账来类比。写文件之前先把我接下来要把哪些块放到哪些位置这个操作意图记到日志区等日志落盘了再去改正式的数据区和元数据区。崩溃后重启时只需要回放日志就能把文件系统恢复到一致状态。Ext3 的日志有三种模式这是面试高频考点也是运维选型容易忽略的地方模式记录内容一致性强度性能影响journal元数据 数据都记日志最强连文件内容都能保证不出现写了一半最慢ordered默认只记元数据但保证数据块先于元数据落盘强文件内容不会出现指向垃圾块的情况中等writeback只记元数据数据落盘时机不保证弱崩溃后可能出现文件内容是旧数据最快我在生产环境一般用默认的 ordered兼顾安全和性能。真要说数据安全要求极高单独上 RAID 电池保护或干脆用带校验的文件系统光靠日志救不了所有场景。2.3 Ext4真正的一次重构很多人以为 Ext4 是给 Ext3 打补丁实际上它做了不少核心重构我挑三个对日常影响最大的讲。第一是Extent区段取代间接块指针。老的数据块寻址方式是给每个文件准备一组指针小文件就算了大文件需要多级间接寻址每次访问都要逐级跳转空间和时间都浪费。Ext4 改用 extent 树直接记录从第几个块开始连续占了多少个块连续空间一个节点就能描述大文件读写效率明显提升。第二是延迟分配Delayed Allocation和 mballoc 多块分配器。写数据时先攒在页缓存里等真正落盘那一下才一次性分配尽量连续的块。好处是碎块更少、写入更连续坏处是一旦断电没落盘的那部分数据会丢。这也是有些人觉得 Ext4 不如 Ext3稳的原因——不是稳是数据丢失窗口变大了。服务器配 UPS理由又多了一条。第三是flex_bg、48 位块号、更大 inode。flex_bg 把多个块组的元数据聚拢存放减少大文件跨组访问的跳转48 位块号把卷上限从 2TiB 撑到 1EiBinode 默认从 128 字节扩到 256 字节能存更多时间戳和扩展属性。一个容易混淆的点Ext4 能挂载 Ext2/Ext3但反过来不行。因为 Ext4 开启 extent 等特性后老文件系统驱动根本不认识这些磁盘结构。我在老服务器上偶尔会把 ext3 的盘挂上来救数据但从不直接开着 ext4 特性往回挂。3. 打开 Ext4 的盘面超级块、块组、inode 与 block3.1 从引导块到块组的宏观布局Ext4 布局从上到下大致是引导块 → 超级块 → 块组描述符 → 一堆块组。引导块只占最前面 1K留给 boot loader文件系统本身不用它。**超级块Superblock**是文件系统的总台账记录的东西包括魔数Magic Numberext 家族固定是0xEF53相当于身份证号块大小、总块数、空闲块数inode 总数、空闲 inode 数特性标志位哪些特性开启/需要支持/只读兼容每个块组的元数据位置这玩意儿一旦坏了整个文件系统就跟失忆一样认不出来。所以 Ext 从设计上就在块组 1、3、5、7…… 等位置存了超级块副本fsck 找备份就是从这些地方下手。**块组Block Group**是空间管理的基本单元。每个组内部的构成是区域作用Block Bitmap一个块一个 bit标记组内哪些块已用Inode Bitmap标记组内哪些 inode 已用Inode Table存放该组所有 inode 本体Data Blocks真正存文件内容的区域位图就是一个格子一个 bit的占用表。Ext2 时代的查找就是在线性位图上扫大分区上创建文件时找空闲块很费劲这也是后来 mballoc 要优化的问题之一。3.2 inode 内部结构文件元数据的存放逻辑inodeindex node索引节点是 Ext 家族最灵魂的概念。它不存文件名存的是除了文件名以外的所有元数据文件类型和权限位属主和属组 ID文件大小、真实占用块数三个经典时间戳atime/ctime/mtime指向数据块的指针extent 树根文件名本身放哪放在父目录的 data block 里。这就形成了目录项dentry→ inode → 数据块三层结构。我们经常用一个类比inode 相当于书的目录页数据块是正文文件名则是目录页上的索引标签。删一个文件本质是删掉目录里那一条记录并释放 inode 和对应数据块unlink 之后文件仍然能读是因为还有进程持有 inode 引用。牵扯到硬链接就更好理解了硬链接是在另一个目录里新增一条指向同一个 inode 的记录inode 里用i_nlink计数引用数归零才彻底销毁。3.3 目录的本质与 htree 大目录索引目录在 Ext4 里就是一个特殊的文件它的内容是一串目录项每项记录inode 号 文件名长度 文件名 类型。Ext2 时代目录项是线性数组要在几百万文件的目录里找一个名字只能从头扫到尾扫描一个 100 万文件的目录卡到怀疑人生。Ext4 引入了 htree哈希树索引把文件名哈希后建一棵树查找时按哈希值走分支复杂度从 O(n) 降到 O(log n)。这个结构在ls大目录时体感特别明显。我做过一次试验10 万个文件的目录ext4 上ls | wc -l一两秒就出来换 ext2 得等十来秒。所以如果你还在用老掉牙的 ext2 挂大目录强烈建议换个思路。3.4 顺带算一笔账Ext2/3 时代文件上限怎么来的这块内容面试经常被问其实就是一个简单的乘法。以 4KB 块大小为例每个块指针占 4 字节一个间接块能放 1024 个指针12 个直接块指针寻址12 × 4KB 48KB1 个一级间接块1024 × 4KB 4MB1 个二级间接块1024 × 1024 × 4KB 4GB1 个三级间接块1024³ × 4KB 4TiB 左右所以 Ext2/3 在 4KB 块下单文件极限大约 4TiB。这个数字背后全是三级指针一层层跳转的成本也是 Ext4 抛弃这套方案的原因。Ext4 用 extent 树后小文件用 4 个 extent 节点直接搞定大文件走树形索引单文件上限直接干到 16TiB早期内核限制卷上限更是能撑到 1EiB。4. 实操全链路亲手创建并体检一个 Ext4 文件系统4.1 分区、格式化、挂载的标准流程纸上谈兵再多不如动手一遍。下面我用一块/dev/sdb演示从零创建 Ext4 的完整流程。先分区。简单场景用fdisk就够了fdisk /dev/sdb # n 新建分区p 主分区一路回车默认起始结束 # w 写入分区表 partprobe /dev/sdb lsblk # 确认 /dev/sdb1 出现然后格式化成 Ext4mkfs.ext4 /dev/sdb1格式化完系统会自动创建一个lostfound目录。这是给 fsck 用的失物招领处——崩溃恢复时找不到父目录的孤儿文件都会被塞到这里。很多新手看到这个目录以为中了病毒其实是正常的。挂载并验证mkdir /data mount -t ext4 /dev/sdb1 /data df -hT /data要让重启后自动挂载最稳的是按 UUID 写 fstabblkid /dev/sdb1 # UUIDxxxx-xxxx TYPEext4 vim /etc/fstab # 追加一行 # UUIDxxxx-xxxx /data ext4 defaults,noatime 1 2最后两个数字1表示需要 dump 备份2表示 fsck 检查顺序根分区才是 1其他分区一般 2。4.2 mkfs.ext4 的关键参数与 inode 密度权衡mkfs.ext4我习惯把三个参数调明白参数默认值影响-b4096块大小影响单文件上限和空间利用率-i16384每多少字节数据分配一个 inode直接决定 inode 总数-I256inode 大小太大占空间太小存不下扩展属性-i这个参数是真正的坑点。默认16384表示每 16KB 数据给一个 inode如果你要存大量 1KB 的小文件inode 会先于空间耗尽。反过来存大视频、大压缩包inode 会富余一大堆。所以我会这样估算如果平均文件 4KB就mkfs.ext4 -i 4096inode 密度拉满如果是纯大文件存储-i 65536都行省下 inode 表的空间留给你装数据。计算 inode 总数也简单容量 ÷ bytes-per-inode。比如 1TB 盘默认-i 16384inode 总数大约是 1TB ÷ 16KB ≈ 6700 万应付一般服务器绰绰有余但扛不住海量小文件场景。4.3 tune2fs/dumpe2fs体检与调优格式化之后日常巡检离不开两个命令。tune2fs -l /dev/sdb1输出超级块摘要我最常看这几个值Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg ... Block size: 4096 Free blocks: 234567 Free inodes: 102345dumpe2fs /dev/sdb1则是把每个块组的信息全部倒出来块组内位图、inode 表位置一清二楚。排查块组异常时非常有用。调整保留块比例建议用tune2fs -m。默认给 root 保留 5% 空间防止 root 用户写日志时被塞满。但数据盘 5% 就太浪费了1TB 盘少了 50GB。我的习惯系统盘保留 5%数据盘保留 0.5% 甚至直接-m 0。tune2fs -m 0.5 /dev/sdb1注意这个操作必须卸载或只读挂载时做。5. 真实故障复盘inode 耗尽、超级块恢复与删不掉的文件5.1 No space left on device 却还有几十 Ginode 排查链路开头说的故障就是最典型的 inode 耗尽。完整排查链路我整理成一套可复用的步骤第一步df -h确认空间没满。第二步df -i看 inode 使用率如果看到IUse% 100%基本锁定。第三步找到哪个目录拖垮了 inodefor d in /data/*; do echo $d $(find $d -xdev -type f | wc -l); done | sort -k2 -nr | head我那次排查出来的元凶是 Java 应用每天生成上百万个临时小文件没清理机制几天就撑爆了 inode。解决方案分两层临时先删旧文件释放 inode长期改文件清理策略或者把目录换到 inode 密度更高的文件系统。如果目录动不了就得重做文件系统在 mkfs 时把-i调小。5.2 超级块损坏后的备份恢复之路另一个经典故障mount 时报bad magic number in super-block其实就是超级块坏了。恢复要用备份超级块。第一步先查出备份位置mke2fs -n /dev/sdb1 # Superblock backups stored on blocks: # 32768, 98304, 163840, 229376 ...-n是 dry-run不会真格式化只是打印格式化时的参数和备份位置。然后从最近的备份尝试恢复主超级块fsck.ext4 -b 32768 /dev/sdb1跑完再挂载一般就正常了。如果主超级块和备份都坏就挑其他备份位置逐个试。遇到这种情况我第一反应是先做块级镜像——dd或ddrescue出来在副本上折腾原盘留着保底。5.3 日志模式与进程占用崩溃后的数据安全还有一个状态很反直觉文件明明被删了磁盘空间却不释放。原因是某个进程还持有该文件的打开句柄。inode 进入了已 unlink 但仍被引用的状态只有进程关闭句柄后才真正释放数据块。排查命令很有用lsof | grep deleted找到占用的 PID 后确认是缓存类进程就重启或让它关掉句柄。如果应用确实还在写这个日志文件正确姿势是通知业务重启而不是直接 kill 了事。另外从数据安全角度说如果应用对单文件一致性要求很高日志模式选dataordered崩溃后保证文件内容要么是新的要么是旧的不会出现内容和大小不一致。想调这个参数可以在 fstab 里改写比如UUIDxxxx /data ext4 defaults,dataordered 1 26. 选型不迷路Ext4 与 XFS、Btrfs 的取舍6.1 三套方案的定位差异先看一张表把常用的三套文件系统关键点放在一起特性Ext4XFSBtrfs单文件上限16TiB早期内核限制8EiB16EiB卷上限1EiB8EiB16EiB日志/一致性日志模式可调元数据日志COW天然一致性在线扩容支持只扩不缩支持快照不支持不支持需 LVM原生快照数据校验无无支持压缩/去重无无支持成熟度极成熟极成熟相对年轻XFS 是老牌高端文件系统元数据用树形结构inode 是按需分配而非预分配一堆所以能容纳的文件数量理论上限极高大文件并发读写下表现很强。但缺点也明显不能在线缩容一旦把分区做大了就回不去。Btrfs 的理念最先进写时复制带来原生快照、校验、压缩、去重。但它在重负载下的性能波动和复杂逻辑引发的各种怪问题这些年坑了不少人。做高危实验之前我肯定优先考虑 Btrfs 能提供快照回滚但真要存必须稳的数据我反而更保守。6.2 我的个人选型习惯与原因给不了万能答案但可以说说我在实际项目里的习惯根分区、/boot、通用小规模服务器无脑 Ext4。理由兼容性最好救援系统里一定认得瞎折腾概率最低。大数据量、海量小文件或并发写入很高的存储服务器优先 XFS。理由inode 动态分配不会在 mkfs 时就把 inode 数量焊死。桌面 Linux 或开发实验机可以考虑 Btrfs快照回滚太爽了但重要数据我依然会定期备份到 Ext4 盘上。嵌入式、SD 卡、U 盘这种小容量非关键场景Ext4 依然稳。一句话总结我的态度在你不确定选什么的时候选 Ext4 基本不会错在你明确知道场景是海量大文件时才考虑 XFS在你需要快照和灵活管理时才为 Btrfs 的复杂度买单。最后再讲一个实操中的小技巧Ext4 的e2fsck支持对只读挂载的盘检查吗不建议。fsck最好在卸载状态下跑非得在线就看一眼fsck -n是否满足你的需求但绝不要在生产上抱着侥幸心态直接fsck -y那会把你整个目录结构按 fsck 的理解重排一遍丢文件是常有的事。我在排查时见过太多因为乱跑 fsck 把损失放大的事故了所以每次动手前先dd镜像、再读一遍dumpe2fs永远比盲操作稳妥。