★ FEATURED ARTICLE 其实很多同学第一次认真接触Linux都是从“分区、格式化、挂载”这三件套开始的。我也是被这几件事折磨过的人之一明明只是想给一块旧硬盘重新整理一下结果发现要在命令行敲mkfs、要理解挂载点甚至格式化之前还得确认文件系统类型。更让我困惑的是网上教程总在反复强调“不要随便格式化”但没人告诉我格式化在底层到底做了什么。直到后来我真正去了解Linux上的Ext系列文件系统——ext2、ext3、ext4——才明白所谓格式化本质上是给一块“只会存0和1的盘子”建立一套管理规则而这套规则中最经典、最常驻于Linux桌面和服务器历史舞台的一族就是Ext。这篇文章我想用一条尽量贴近实际使用的路径把Ext文件系统从“初见”到“能看懂底层结构”讲清楚。适合刚接触Linux的初学者也适合想给旧设备重新安排文件系统的朋友温习一遍底层逻辑。1. 没有文件系统的时候硬盘只是按编号排列的格子1.1 磁盘的物理与抽象层级要理解文件系统得先想清楚一个问题硬盘在没有文件系统时到底长什么样物理层面磁盘由盘片、磁头、磁道、扇区组成但现代系统不会让应用直接跟这些物理概念打交道。操作系统看到的是一个个逻辑块块的大小通常是512字节或4KB。你把整块盘想象成一张巨大的稿纸纸上按顺序画满了等大的格子每个格子都有自己的门牌号。操作系统提供的读写接口本质上就是“把第N号格子里的数据读出来”和“把数据写进第N号格子”。这个接口非常原始跟人类的认识习惯完全对不上。我经常用一个比喻这就像一间没有任何贴标签的大仓库物品你可以随便乱放但如果要找到其中某一件就只能知道它在仓库的哪个“编号位置”。现实世界里没人会这么管理仓库计算机也一样。文件系统就是那一套贴标签、编目录、记录物品信息的管理制度。没有它的时候磁盘虽然也能读写但应用软件必须自己记住“我的数据在哪一块”这在多用户、多程序、多文件的场景下根本无法维护。1.2 文件系统的职责是给磁盘区域做“检索表”文件系统出现后它把自己管理的区域切分成更细的单元每个文件占据若干个数据块文件系统负责记录哪个块属于哪个文件、哪个块空闲可用、目录层级怎么组织。这就像一个数据库底层用位图记录“哪些格子被占了”用索引结构记录“文件的元数据在哪里”用目录项记录“文件名和索引号怎么对应”。我当时第一次听到这些词脑子里其实是一团浆糊。后来想想真正的切入点不应该是一头扎进ext2/ext3/ext4的细节而是先建立一张地图概念一句话理解类比块Block文件系统读写数据的最小单位仓库里的一个箱子位图Bitmap记录哪些块空闲、哪些被占用箱子上的“有空/已满”牌子索引节点inode记录文件属性与数据块位置物品的清单卡片目录项dentry记录文件名到inode的映射仓库门口的分类索引超级块Superblock记录整个文件系统的全局信息仓库总台账有了这张地图再回头看Ext系列会发现它的一切进化都是在优化这套“箱子、卡片、台账”体系的效率与安全。这也是为什么我没有直接讲命令而是先用一节的篇幅聊这些基础。2. 从ext到ext4为了“断电不丢数据”一路改出来的家谱2.1 ext2时代的稳与痛Ext系列的第一代版本其实很朴素真正在历史上留下深远影响的是ext2。ext2的设计很经典用块位图管理空间用inode描述文件用目录项组织层级。这些基础设计至今仍被沿用足见当时设计者的眼光。它最大的优点在于结构简单、文档清晰、兼容性强而最大的痛点用一句话概括就是掉电之后非常脆弱。为什么脆弱因为ext2没有日志journal机制。你写一个文件的时候文件系统可能要同时更新好几处数据inode里新增的块指针、块位图里被占用的标记、目录项的变更。如果写了一半突然断电这些位置的数据可能处于“一半新一半旧”的混乱状态。系统重启后内核只知道文件系统“脏了”需要完整扫描整块磁盘来检查一致性。这个检查在早期几GB容量时还好等到磁盘发展到几百GB甚至更大一次开机自检可能花几十分钟甚至更久。我在一台老旧笔记本上见过ext2分区因为异常关机开机后扫描了接近半小时那种感觉至今难忘。2.2 ext3加入日志一次断电后的自救能力ext3的出现解决了ext2最让人头疼的“断电扫描”问题。它引入了一个新机制——日志journal。打个比方ext2像一个人在自己的笔记本上直接乱写写一半被人抢走笔再拿回来时页面对不上ext3则像先在这本笔记前面垫一张“草稿纸”每次改动前先把“我要怎么改”写在草稿纸上实践完再做个标记。具体落到磁盘上ext3会预留一份日志区域。写入流程大致是先规划好几个要更新的数据块把“这些改动即将发生”写进日志然后真正修改数据最后在日志里记录这些改动已经完成。如果中途断电重启后文件系统只需回放日志把未完成的操作回滚或补齐而不用满盘扫描。这个改变让磁盘恢复时间从“分钟级、小时级”变成了“秒级”。ext3的日志还提供了三种模式按安全性和性能排序模式行为适用场景journal数据先写日志再写实际位置对安全要求极高、性能损失可接受ordered只把元数据写日志但保证数据块先落盘默认模式安全和性能兼顾writeback只写元数据日志数据顺序不强制追求性能能容忍极端情况下文件内容损坏我推荐日常场景都保持默认的ordered模式。它已经能在停电后避免大多数损伤同时性能损失相对可控。而writeback虽然快一点但万一断电可能出现文件名和目录结构完好、文件内容却是旧的甚至错乱的尴尬情况对普通用户来说很难排查。2.3 ext4的现代化改造ext4继承了ext3的日志机制在这个基础上又做了几项关键升级。第一是引入了extent区段机制。原来的ext2/ext3采用块指针列表每个文件的数据块地址被逐个记录下来遇到大文件就要维护很长的指针列表。ext4则在inode里记录起始块号和连续块数一个区段就能表示一大段连续空间。这对大文件特别友好既节省inode空间也提升了访问效率。第二是延迟分配delayed allocation。简单说文件系统在写入数据时不再每写一个块就立刻申请分配而是先在内存里攒一攒等到真正要落盘时再做整体分配。好处是能让文件块尽量连续减少碎片。坏处是如果写入时系统崩溃内存里的延迟写入数据可能会丢失甚至文件大小为0。所以对正在开展重要数据写入的桌面环境来说我还是建议保持稳定供电或者给笔记本开启正确的处理策略。第三是容量上限的大幅提升。ext4理论上可支持单文件最大16TB在4K块大小下、文件系统最大1EiB这已经远超过绝大多数实际应用场景。与此同时它延续了ext系列一个非常大的优势可以无需重新格式化直接从ext2/ext3升级而来。我在一些老服务器上做过原地升级先降级ext3的日志功能再开启ext4特性整个过程风险控制得当的话数据可以完整保留。这种向前兼容的特性是ext4至今仍是Linux默认文件系统的重要原因之一。3. 磁盘上的“行政区”超级块、块组、inode和目录项3.1 超级块全局户口册在一张刚完成格式化的Ext磁盘上最先被写进的数据区域里一定包含超级块。超级块里记录着整个文件系统最关键的全局面板数据块大小、总块数、空闲块数、inode总数、空闲inode数、文件系统UUID、挂载次数、最后挂载时间、最后写入时间以及可调用的特性位。我习惯把超级块理解成这个分区上的“户口册”。文件系统自己从哪里起始、每个块组划分多大、日志区在哪里、哪些高级特性被开启全都要查这里。如果超级块损坏整个分区基本就瞎了。所以Ext文件系统在设计时会在多处冗余存放超级块副本而不是只放一份。这也是为什么e2fsck扫描时经常能看到“找备份超级块”的提示。查看超级块信息最常用的命令是tune2fs -l和dumpe2fs你不需要解包任何神秘工具用这两条命令就能看到一份非常清晰的全局面板tune2fs -l /dev/sdb1它会打印几百行信息包括文件系统状态、块计数、inode计数、特征标识等。第一次看可能眼花但重点只看几个字段就够了Block count、Block size、Inode count、Free blocks、Free inodes。3.2 块组把大磁盘切成本地街区超级块管理全局但真正让磁盘高效运转的是“块组”机制。假设整块盘有一千万个块如果只有一个全局位图来记录空闲和占用那每次要分配一个块都得扫描整张位图性能会很差。Ext把磁盘按固定大小切成许多块组每个块组内部自带一份位图、一份inode表以及数据区。这就好比一个大型图书馆如果只有一个总目录所有人查书都要跑到一层大厅效率太低。更好的做法是每层楼设一个小阅览室本层书架情况就在这层处理只有涉及全馆统计时才看总目录。块组机制也正是基于这种局部性思想文件系统创建时尽量把相关数据放在同一个块组内减少磁头跳转。块组描述符表记录了每个块组的起始块号、位图块号、inode表起始块号。为了保险这份描述符表在磁盘上也有冗余备份。当你在dumpe2fs输出里看到连续的Group N行时就是这些结构在工作。3.3 inode与目录项文件名到数据块的“寻址链”inode可以说是Ext文件系统的灵魂。每个文件或目录都有一个inode里面保存文件类型、权限、所有者、大小、时间戳以及指向数据块的指针。系统看到一个路径时比如/tmp/a.txt它从根目录的inode出发去目录内容里找“tmp”这个目录项对应的inode号再进到tmp的inode读取tmp目录内容找到“a.txt”的inode号最后才通过这些指针读出文件的数据块。这里有一个容易混淆的点文件的“内容”不在inode里inode里只有“指针”。就像图书馆的索书号卡片上只记录书名、作者和书架位置不保存整本书的内容。同时文件名也不是存在inode里而是存在它所在目录的数据块中。目录本质上就是一个特殊的文件它的数据区存放着“名字——inode号”的映射条目。这就是为什么Linux里可以给同一个inode创建多个硬链接多个目录项指向同一个inode号文件数据只有一份每个硬链接看起来都像“真的文件”。我见过不少新手把“硬链接”和“软链接”搞混。软链接符号链接是一个独立的小文件里面存的是另一个路径的字符串硬链接则是直接增建了一条指向同一inode的目录项。对Ext来说硬链接的操作对象是目录项和inode引用计数不复制数据这也是ext对“链接数”字段存在的原因。理解了这个链条后面看stat命令的“Links”字段就会很清楚。4. ext4之外还有谁跟xfs、btrfs对比怎么选4.1 三大家族的性格差异Ext4并不是Linux世界里唯一的选择。尤其在服务器场景xfs和btrfs的曝光率一样很高。这三者有着完全不同的设计取向xfs最初为大型服务器和高并发场景设计使用B树组织数据支持动态扩展在大文件、多并发读取时表现出色。它的文件系统在运行几十TB时依然能保持良好的性能与稳定性因此很多企业级发行版会把它作为默认文件系统。btrfs则是奔着“现代化”去的主打写入时复制CoW、子卷快照、数据校验、压缩等特性。听起来很美好但你可以在同一个分区上做多个子卷随时打快照往回滚这在满足试验性需求时非常方便。代价是历史稳定性不如ext4碎片管理复杂在大量小文件写入下性能波动明显。Ext4的优势恰恰在于“传统”结构经过多年打磨工具链成熟问题排查资料丰富从救援工具、数据恢复软件到自动化运维脚本都有大量兼容支持。它不追求大而全但出问题时可预料、可推断。我把三者放在一张表里对比方便直观感受维度ext4xfsbtrfs设计重心传统通用、高兼容大文件、高并发读取快照、校验、CoW最大单分区1EiB级别实际依赖实现超大容量表现优异设计容量大使用复杂时碎块多日志机制日志成熟默认ordered元数据日志写入优化强无传统日志靠CoW实现一致性快照不支持可选支持需额外手段内建子卷快照数据校验默认无默认无默认内建并校验和运维资料极多多中等坑也多4.2 我的选型建议如果你问我在个人环境中怎么选我的看法是不要为了“先进”而放弃“熟悉”。桌面Linux、系统盘、移动硬盘我基本还是用ext4。理由很简单数据无价而ext4的救援方法论最完备真正用坏了你也能找到足够多的资料来恢复或补救。如果跑一台专门存大文件的服务比如视频素材库、备份仓库我倾向用xfs它对大文件和删除重写场景更友好。注意xfs不能直接缩容分区建错了要缩小空间会非常麻烦创建前要想清楚整体磁盘布局。btrfs适合喜欢折腾、重视快照体验的玩家比如你在做成套实验环境或想要轻量备份。但你一定要接受一个现实它需要更频繁地关注状态定期检查否则遇到问题可能连专业人士都头疼。普通用户想省心“常用常新”的btrfs不是首选。还有一个很容易忽略的点文件系统的选择还与具体发行版默认安装器有关。有的发行版默认用xfs有的默认用ext4。如果你不太熟悉内部差异那就跟着安装器默认走反而是最稳妥的选择毕竟发行版的默认选项是经过最多兼容性验证的。我自己在默认xfs的发行版上就不会强行改成ext4在默认ext4的环境里也不会因为好奇而换成btrfs。5. 在你自己机器上验证一遍ext结构5.1 先认清楚你手上是什么文件系统纸上聊完还得动手。首先你得确认某块分区实际用的什么文件系统。命令不复杂df -hT输出里TYP列会告诉你每个挂载点对应的文件系统类型如果你想知道某个磁盘分区的文件系统类型即使它没挂载用lsblk -f /dev/sdb这条命令会直接列出设备的分区结构、文件系统类型和UUID。我实际排查时还有一个习惯用blkid /dev/sdb1查看它会给出详细UUID适合在写/etc/fstab时确认对应用的是哪个分区。5.2 用dumpe2fs和tune2fs“看穿”磁盘结构一旦确认分区是Ext系列常见是ext4下一步就是观察它的内部结构。dumpe2fs /dev/sdb1 | head -40打印出来的前几十行明显带着超级块特征Inode count、Block count、Block size、Flex block group size、Mount count、Check interval等。再往后面看会进入Group行直到出现“Group 0”dumpe2fs /dev/sdb1 | grep -A 10 Group 0这里能看到块组0的块位图位置、inode位图位置、inode表起始位置、空闲块数、空闲inode数、已用目录数等。这组数字可以直接和上面讲的“块组”机制对上号。我第一次看到时真的有“原来磁盘内部长这样”的感觉。如果想确认某个文件具体存在哪个inode号、数据块怎么分布两条命令是ls -i /path/to/file stat /path/to/filels -i只给inode编号stat则给权限、大小、块数、访问时间。在ext4上你还可以用filefrag查看文件物理块的碎片情况filefrag -v /path/to/file5.3 inode耗尽有空间却写不进文件的真实案例很多新手以为磁盘满了就是“空间不够”但在Ext上还有一种更隐蔽的满法inode满了。inode在格式化时数量固定每个文件或目录都要占用一个。如果文件系统里创建了大量几十字节的小文件比如几千个缓存文件、日志碎块那么空间可能还剩很多inode却先告急。判断是否遇到这种情况只看df -h不够要看df -i在Inodes列和IUsed列如果使用率到100%表现就是创建新文件时报“No space left on device”但df -h明明显示有几个G空闲。我实际遇到过一台装了海量小图片的服务器分区空间剩余一半但inode全满了一开始还把错误定位在磁盘空间上折腾了半天才反应过来。解决思路有几个如果分区还不大且数据可以迁移重建文件系统并调大inode密度如果没法重建就得想办法清理大量小文件比如把日志归档、合并碎文件或者把这类数据转移到其他文件系统上。对于还来得及规划的场景我建议创建分区前就想清楚用途大量小文件场景下可以指定更大的inode字节比。5.4 常见坑与调优经验最后分享一些我在实际使用中踩过的坑。第一个是关于lostfound目录。每个ext文件系统根目录下都有这样一个目录它是e2fsck在恢复交叉链接或孤立文件时存放“无家可归”文件的地方。如果你发现里面凭空多了文件别急着删先看看内容是哪些数据很可能是一次异常断电后的产物。第二个是挂载参数。ext4挂载时支持很多选项常见的包括noatime不记录访问时间、discard启用TRIM对固态盘友好。如果你的分区是固态盘我建议在/etc/fstab里打开discard现在很多发行版默认已经有了同时开启noatime可以减少不必要的写放大。反之如果是机械硬盘开TRIM意义不大反而增加固态盘无法正确识别的风险。第三个是干净卸载。虽然ext3/ext4的日志让异常断电后的恢复速度快了很多但每次异常断电依然会对文件系统形成压力。我习惯在长时间运行后的机器上执行sync、确认没有关键任务再卸载如果卸载时提示“target is busy”多半是有进程持有文件句柄可以lsof D /mountpoint找出占用进程而不是强行用umount -l。强制删除挂载不是不能用但留给自己的可排查信息越少就越容易让下一次错误变得更难定位。第四个经验是ext系列对扇区大小有一定兼容性但如果你在很老的盘或虚拟磁盘上格式化块大小不稳定时最好先检查设备逻辑扇区大小。mkfs.ext4默认会按设备报告的信息设置如果设备本身虚报了容量格式化出来可能使用时才发现数据布局异常这种问题很难救。这些点放在平时可能觉得只是“注意事项”但真正经历过一次inode耗尽、一次掉电后恢复、一次lostfound惊魂你就会明白Ext为什么能在Linux世界里坚守这么多年它的结构让你看得懂、查得了、恢复起来也有章可循。我对文件系统的态度一直都是你可以不研究底层的每个字节但你至少要能在出问题时说出“我挂载的是什么类型的文件系统、它的大致结构长什么样、往哪里查日志和元数据”。掌握了这套再面对其他文件系统时你会发现大原则都是相通的。下一次遇到分区问题时希望你能先想起这些块组和inode的概念而不是一上来就格式化。
阅读完成 · 觉得有帮助？
