凌晨两点被告警叫醒df -h显示/data已经跑到 100%可du -sh把整个目录加起来才 40G盘是 200G 的 xfs。第一反应是排查日志暴涨第二反应是检查有没有被删的文件没释放句柄最后xfs_info一看是写入密集型任务把投机性预分配撑起来了。这类问题在 ext4 上出现的形态又完全不一样——ext4 更常见的是 inode 用尽、保留块吃掉了 5%、或者日志回放卡在只读挂载。同样一句磁盘满了背后是两套完全不同的元数据组织方式。Linux 文件系统 ext4、xfs 这些名词几乎每个人在装系统那天都见过一次然后就再也没深究过。选哪个格式化多数人是看发行版默认值Ubuntu 22.04 装机默认 ext4RHEL/CentOS/Rocky 系默认 xfs。这个默认值其实是发行版替你做的一次判断判断依据是这台机器大概率会怎么用。如果你只是桌面刷网页随便哪个都够用可一旦涉及数据库、容器镜像分层、日志盘、备份盘、嵌入式只读根文件系统选型和挂载参数就会实打实地影响吞吐、延迟和故障恢复时间。这篇内容我想把这些年踩过的坑捋一捋从 VFS 抽象层讲到 mkfs 参数再到出问题时怎么一步步定位适合刚接触 Linux 运维的朋友也适合已经用了几年但没系统梳理过的人。1. 从一次磁盘写满说起文件系统选型不是随便格式化一下1.1 VFS 那层抽象把差异都藏起来了应用调用open()、read()、write()的时候从来不关心底下是 ext4 还是 xfs。真正干活的是内核里的 VFSVirtual File System层它定义了四个核心对象super_block描述一个已挂载的文件系统、inode描述一个文件或目录的元数据、dentry目录项负责路径名到 inode 的映射、file描述一个被打开的文件实例。每个具体文件系统要做的就是实现自己的一套super_operations、inode_operations、file_operations。这套抽象的好处是生态统一坏处是很多性能差异被掩盖了。同样一个write()ext4 可能先在页缓存里攒着、等回写时再一次性分配磁盘块xfs 则倾向于在写入点附近就预留一段连续空间。你在应用层看到的接口一模一样落到磁盘上的块布局、元数据更新次数、日志写入量完全不同。很多人调优调不动问题就在于只盯着应用层参数没往 VFS 下面看一层。理解这层结构后面讲 inode 耗尽、句柄泄漏、删了文件空间不释放这些现象时会顺畅很多——它们全都是 VFS 对象和文件系统元数据之间配合的结果。1.2 同一块盘换个文件系统结果能差多少我做过一个不太严谨但很有说服力的对比同一台虚拟机100G 虚拟盘分别格成 ext4 和 xfs跑同样的场景——先创建 20 万个 4K 小文件再删掉然后追加写一个 8G 的大文件。差异主要出现在三个阶段操作阶段ext4 表现xfs 表现创建 20 万小文件元数据写入密集明显慢一些分配组并行度高快一截删除 20 万小文件相对干脆走到一定量后开始变慢元数据日志压力上来追加写 8G 大文件稳定延迟分配效果不错稳定预分配让碎片更少创建单个 50 万文件的大目录有 dir_index 撑着还行B树目录遍历更稳这个表不是让你背结论而是想说没有更快的文件系统只有更贴合当前负载的文件系统。小文件海量创建看的是元数据并发能力大文件顺序写看的是块分配策略删除性能看的是日志和数据结构的清理成本。把负载特征先摸清楚选型才有依据否则就是凭感觉拍脑袋出问题的时候连从哪查都不知道。2. ext4 的骨与肉日志、区段、延迟分配到底在解决什么2.1 从间接块到 extentext4 最大的那次进化ext2/ext3 时代一个文件的数据块是靠间接块串起来的inode 里存 12 个直接块指针再加一级、二级、三级间接块。文件越大查一个块要跳的层数越多大文件随机读的代价很高。ext4 引入的extent换了个思路——不再记录第 N 个块在哪而是记录从第 X 个逻辑块开始连续 Y 个块对应磁盘第 Z 个物理块。一个 extent 用几个字节就能描述上千个连续块元数据量直接降了一个数量级。这个改变对视频、镜像、数据库数据文件这种大块连续写的场景收益极大。你去看filefrag -v的输出就能感受到一个正常写入的大文件ext4 上通常只有几十个 extent而老的 ext3 可能是几万个块指针。extent 树本身也是一棵 B 树文件极大时会从 inode 内联存储溢出到独立块里这叫 extent tree 的深度增长。理解这一点之后你就会明白为什么fallocate预分配对 ext4 特别有效——它直接把 extent 树搭好避免了后续写入时反复分裂节点。2.2 日志的三种模式dataordered 为什么是默认值ext4 是日志型文件系统但它的日志记的是元数据不是数据本身。这就有个经典问题如果元数据说文件已经写了 4K但实际数据块还没落盘掉电重启后就会读到一块垃圾。ext4 用三种模式处理这个矛盾datajournal数据和元数据都进日志一致性最好写入量大约翻倍性能最差。几乎只在对数据一致性有极端要求的场景才用。dataordered默认值。元数据进日志但保证数据块先落盘、元数据事务后提交。既保证不会读到垃圾数据性能又比 journal 模式好得多。datawriteback只保证元数据一致不保证数据先落盘。理论上可能读到旧数据或者新文件里的脏块性能最高风险也最大。实际生产里我基本只用默认的 ordered。有人为了压榨 IO 性能改成 writeback如果你的应用自己做了 fsync 并且对文件内容有校验比如数据库有自己的页校验和风险可控但如果是个普通的日志采集程序掉电后读出一堆莫名其妙的字节排查起来能耗掉一整天。这个选项不是越高越专业而是看谁在替你兜底。2.3 延迟分配和多块分配器才是 ext4 性能的关键ext4 默认开启delayed allocation延迟分配write()调用返回时数据只进了页缓存磁盘块还没真正分配。等到回写线程把脏页刷出去的时候内核已经攒了一批写请求可以挑一段连续的空闲空间一次性分配。这个攒一攒再决定放哪的策略是 ext4 相比 ext3 碎片率大幅下降的主因。配套的是mballoc多块分配器它一次能给一个文件分配多个块而不是一块一块地找。两者叠加的效果在顺序写场景下非常明显。但延迟分配也有它的副作用最典型的就是进程写了一大堆数据然后崩溃df显示空间被占用了du却统计不到——因为脏页归属在页缓存上还没落到具体的文件 inode 上。遇到这种情况别慌先sync一下再看数据回写完成后统计就一致了如果sync卡住不动那才是真有问题。2.4 inode 数量一个出厂就定死、事后很难改的参数mkfs.ext4会在格式化时按比例预分配 inode默认大概每 16KB 空间一个 inode。这个数字一旦定下来不能在线增加。如果你要存的是海量小文件邮件队列、缩略图、缓存目录很容易出现磁盘还有 50G但就是创建不了文件的情况报错是No space left on device而df -h显示空间充足。这时候要看的是df -i。# 查看 inode 总量、已用、剩余 df -i /data # 查具体文件系统的 inode 大小和总数 sudo dumpe2fs -h /dev/vg0/data | grep -E Inode count|Inode size|Block count补救办法只有两条一是把部分数据迁到另一个文件系统二是备份后重新格式化并加大 inode 比例比如mkfs.ext4 -i 8192每 8KB 一个 inode。我自己的经验是凡是明确要放小文件的盘格式化时直接用-i 8192甚至-i 4096代价是多占一点元数据空间换来的是不会在半夜因为 inode 耗尽被迫做数据迁移。3. xfs 的另一种解法分配组、B树与大规模并发的取向3.1 AG 和 B树让 xfs 在海量并发下更从容xfs 诞生于 SGI 的服务器环境设计目标从一开始就是多 CPU、大文件、高并发。它最核心的结构是allocation groupAG——把整个文件系统切成若干等份每份有自己独立的空闲空间 B树和 inode B树。多个写线程落在不同 AG 上时锁竞争极小这就是为什么 xfs 在多核机器上创建小文件、写大文件时通常比 ext4 更稳。目录在 xfs 里也是 B树组织单个目录塞几十万文件查找依然是 O(log n)。这点在实际运维里很实用日志归档目录经常一个月攒出几十万个文件ext4 虽然有 htree 撑着不至于崩但 xfs 的遍历和删除都更可预期。mkfs.xfs时的agcount参数就是控制切多少份# 查看当前文件系统的 AG 数量、块大小、inode 大小 xfs_info /data # 格式化时指定 8 个分配组、512 字节 inode sudo mkfs.xfs -f -d agcount8 -i size512 /dev/vg0/dataAG 数量不是越多越好。太少会让并发写入挤在同一棵树上太多则每个 AG 的最小空间开销累加起来浪费容量小容量盘尤其明显。默认值通常是内核按 CPU 数和容量算出来的我一般只在明确的多线程写密集场景才手动调而且会先用小盘实测一轮。3.2 只能涨不能缩mkfs 时的决定要一次做对xfs 最让人纠结的一点可以在线扩容不能收缩。xfs_growfs挂载状态下就能扩扩完立即生效这在 LVM 环境下非常舒服。但反过来如果你发现分多了想缩回去只能备份、重建、回灌。这个特性直接影响分区规划思路。我的做法是用 LVM 打底逻辑卷先只给一个保守的大小后面按需lvextendxfs_growfs逐步加。宁可一开始给少点、后面慢慢涨也不要一次给满然后发现没得退。另外 xfs 的日志log在 mkfs 时确定位置和大小-l size...参数决定了日志区多大——写密集型负载建议适当加大比如给到 512M 甚至 1G可以减少日志刷盘频率但日志太大也没用而且它是按外层 stripe unit 对齐的配错对齐参数反而拖慢性能。# 扩容完整流程LVM 加空间再让 xfs 感知 sudo lvextend -L 50G /dev/vg0/data sudo xfs_growfs /data注意xfs_growfs的路径参数是挂载点不是设备名这是新手最容易写错的地方而 ext4 那边的resize2fs接的是设备路径。两个命令的参数习惯正好相反混用的时候会报一堆莫名其妙的错。3.3 投机性预分配那个让 df 和 du 对不上的元凶回到开头那个场景。xfs 为了防止文件碎片化会在写入时投机性地多留一段空间——预计你可能要继续写就先把后面一段预留出来。这个预留在文件关闭或一段时间无写入后会释放但在持续写入的过程中df看到的就是被占用了。表现就是df说用了 190Gdu加起来只有 140G差了几十 G。多数情况下这属于正常行为不需要处理。可以用挂载参数allocsize64m之类调小预分配粒度或者用xfs_fsr做在线整理。但如果差异持续存在且不断增长就要怀疑是不是有进程在持续写并且没正常关闭文件。我的排查顺序是先看是不是小文件密集写入这种最容易触发再看有没有长期打开的大文件句柄最后才考虑调 allocsize。4. btrfs 和其余候补快照、校验和背后的真实代价4.1 CoW 与快照好用的另一面是碎片和写放大btrfs 的卖点很吸引人写时复制CoW、子卷、秒级快照、数据校验和、内置 RAID。做容器或者需要频繁回滚的环境这些能力确实省事。但 CoW 的本质是改数据不覆盖原位置而是写到新位置再改指针带来两个绕不开的代价碎片化和写放大。一个文件反复修改它的数据块会散落到磁盘各处机械盘上顺序读退化成随机读SSD 上虽然随机读不敏感但写入量翻倍会加速寿命消耗。btrfs 为此提供了nodatacow属性可是关掉 CoW 之后那些依赖 CoW 的能力快照、校验和、压缩也就一起没了。这就是典型的鱼和熊掌功能是绑在一起的不能用我只要 A 不要 B的思维去挑。4.2 为什么我不建议在数据库数据盘上默认上 btrfs数据库通常自己做了页校验、自己有 WAL、自己管理 IO 顺序。btrfs 在上面再叠一层 CoW 和校验和等于重复劳动还额外多了写放大。更麻烦的是随机写场景下的碎片增长跑几个月之后性能下降明显得靠btrfs balance整理而这个操作本身很重生产环境跑起来提心吊胆。同类候补还有几个各有各的地盘f2fs为闪存设计日志结构化手机、UFS/eMMC 设备上常见。U 盘、SD 卡这类场景比 ext4 更友好。zfs企业级存储的常客快照和校验能力强但内存吃得多许可和发行版集成情况要看具体环境。overlayfs容器镜像分层的核心它本身不是存数据的文件系统而是把多个只读层加一个可写层叠起来的联合挂载。squashfs只读压缩文件系统Live 镜像、固件根文件系统常用。tmpfs内存盘重启即失/dev/shm、/run都是它。选它们的关键不是哪个更先进而是这个场景最怕什么。怕掉电丢数据就选日志稳健的怕小文件多就选元数据并发高的怕空间浪费就选支持在线收缩的怕回滚麻烦就选支持快照的。把最怕的那件事排第一位答案基本就出来了。5. 格式化参数不是玄学mkfs 和 mount 选项逐条拆5.1 4K 对齐与 RAID 条带一个常被忽略的性能开关现代磁盘包括 SSD 和 512e 机械盘的物理扇区普遍是 4K如果分区起始扇区没对齐一次逻辑写会横跨两个物理扇区触发读改写性能直接打折。好消息是现在主流的parted、fdisk默认都按 1MiB 对齐基本不会踩这个坑但如果你手工指定过起始扇区就得自己确认# 看分区的起始扇区能被 2048 整除基本就是对齐的512B 逻辑扇区下 sudo fdisk -l /dev/sda # 用 parted 检查并自动选择最优对齐 sudo parted /dev/sda align-check optimal 1在 RAID 上还有一层mkfs.ext4的-E stride和-E stripe-widthmkfs.xfs的-d su和-d sw。它们的含义是告诉文件系统底层一次条带写入跨了多少块。如果不设置文件系统会按单盘假设去分配导致每次分配正好卡在条带边界上需要读改写校验。设对了顺序写吞吐能有肉眼可见的提升。# 假设 RAID55 块盘chunk 64K4K 块大小 # stride 64K / 4K 16stripe-width 16 * (5-1) 64 sudo mkfs.ext4 -E stride16,stripe-width64 /dev/md0 # xfs 对应写法su/sw 单位是字节 sudo mkfs.xfs -d su64k,sw4 /dev/md0注意 RAID5/6 的有效数据盘数是总盘数 - 校验盘数这个减法经常有人忘记算出来的 stripe-width 偏大反而更差。5.2 mount 选项哪些真有用哪些是历史包袱挂载选项是最容易抄作业抄错的地方。网上流传的老教程里有些选项在新内核里已经默认开启或者已经废弃照抄反而增加困惑。选项作用我的实际建议noatime不更新文件访问时间强烈建议开。能省掉大量元数据写收益稳定nodiratime不更新目录访问时间noatime已包含不用单独写relatime访问时间有节制地更新现代发行版默认兼容性优先就留它discard实时 TRIM不建议。同步 TRIM 会拖慢删除改用fstrim.timerbarrier0关闭写屏障除非你在有断电保护的阵列上且明确知道后果否则别关dataorderedext4 数据一致性模式默认值别动nobarrier新版内核已不推荐已废弃写法不要用关于discard我想多说一句。很多人一看 SSD 就习惯性加上结果删除大量小文件时 IO 延迟飙升因为每次删除都要同步发 TRIM 命令。正确做法是挂载时不加discard改用定期批处理# 启用每周自动 TRIM sudo systemctl enable --now fstrim.timer # 手动跑一次看看能回收多少 sudo fstrim -av这套组合在有大量删除操作的盘上效果立竿见影而且不影响日常删除的响应速度。5.3 保留块ext4 出厂预留的那 5%ext4 默认给 root 预留 5% 的空间目的是防止普通用户把盘写满后系统进程连日志都写不进去。这个设计在系统盘上很合理但在纯数据盘上就纯属浪费。200G 的盘白扔 10G谁都不乐意。# 把 /data 的保留块比例降到 1% sudo tune2fs -m 1 /dev/vg0/data # 确认修改结果 sudo tune2fs -l /dev/vg0/data | grep Reserved block count降到 1% 甚至 0 都可以前提是这个盘不承担系统关键写入。xfs 没有这个概念它的空间利用率天然更实这也是很多人觉得同样容量 xfs 能多装东西的原因之一。6. 出问题时怎么查一条从表象到根因的排查链路6.1 df 和 du 对不上先把可能性列全这个现象太常见了别一上来就怀疑文件系统坏了。按下面顺序过一遍八成能找到原因被删除但句柄未释放最经典的一种。进程还开着文件rm之后目录项没了但 inode 和数据块还占着。用lsof L1或lsof | grep deleted找出来重启对应进程或让它重新打开文件即可。脏页还没回写前面说的延迟分配。sync一下再看通常会一致。xfs 投机性预分配差异几十 G 且写操作仍在进行属于正常。挂载点被覆盖某个目录本来有数据后来在上面又挂了一个文件系统原数据被盖住了du统计不到但空间确实占着。mount一下看看有没有重复挂载点。稀疏文件和硬链接du默认按实际占用算df按块算本身就有差异du也会对硬链接去重。# 找出已删除但仍被占用的文件按大小排序 sudo lsof L1 2/dev/null | sort -k7 -n -r | head -20 # 或者直接看进程的 fd 目录 sudo ls -l /proc/PID/fd | grep deleted6.2 只读挂载和日志回放先别急着 fsck文件系统突然变成只读通常意味着写操作出了错内核为了保数据一致性主动降级。这时候dmesg里一般有明确的原因可能是 IO 错误、可能是元数据校验失败、也可能是后端存储断了。# 第一步永远是看内核日志 dmesg -T | tail -50 journalctl -k --since 10 min ago如果只是 IO 瞬断导致的修复后端后重新挂载即可。如果是元数据损坏ext4 会在挂载时尝试日志回放回放失败才会提示需要fsck。未挂载状态下跑e2fsck -f是标准动作xfs 那边对应的是xfs_repair同样必须卸载先跑一次-n做只读检查看看会改动什么# ext4卸载后检查修复 sudo umount /data sudo e2fsck -f -y /dev/vg0/data # xfs先干跑一遍确认要改什么再实际执行 sudo umount /data sudo xfs_repair -n /dev/vg0/data sudo xfs_repair /dev/vg0/data有个细节xfs 如果日志区本身损坏xfs_repair会提示需要-L强制清空日志这个参数会丢日志里的待回放事务可能导致最近几秒的数据不一致。用之前务必确认能接受这个损失。6.3 简化的决策表先分场景再动手现象优先排查常用命令空间满但 du 很小句柄泄漏、预分配、覆盖挂载lsof L1、xfs_info、mount空间够但创建文件失败inode 耗尽df -i、dumpe2fs -h突然只读IO 错误、元数据损坏dmesg -T、journalctl -k大量小文件操作变慢碎片、目录过大、日志压力filefrag、xfs_fsr删除很慢实时 TRIM、元数据清理关discard、改fstrim.timer7. 场景对照不同负载下我会怎么选7.1 数据库数据盘稳定压倒一切数据库最怕的是延迟抖动和掉电后数据不一致。ext4 的 ordered 模式和 xfs 的元数据日志都能保证崩溃一致性选哪个更多看团队熟悉程度——熟悉的那个在出故障时能更快定位。我个人的默认倾向是 xfs因为大文件顺序写和并发 IO 处理更平滑而且在线扩容不会中断服务。但有一条硬要求数据盘上的 fsync 语义必须清楚。数据库自己会频繁 fsync这时候挂载选项里的barrier千万别关存储控制器上的写缓存如果没有电池保护也要配成写穿模式否则等于把数据安全交给运气。7.2 容器宿主和镜像分层overlayfs 之上的选择容器场景分两层看。上层是 overlayfs 负责镜像分层它需要一个可写层的落脚点通常放在/var/lib/docker或者/var/lib/containerd。这个目录下层文件系统是什么直接影响容器的启动速度和空间回收效率。xfs 在这个场景下更常见原因是它对大量并发创建/删除的元数据处理更稳而且 Red Hat 系默认就是 xfs工具链踩坑少。如果你的场景需要频繁做容器文件系统快照回滚那 btrfs 或 zfs 的子卷能力确实省事。但要接受 CoW 的写放大最好配 SSD 并且留足空间。我自己试过用 btrfs 跑容器宿主跑了两个月之后碎片问题开始显现最后还是回到 xfs overlayfs 的组合回归简单可靠。7.3 嵌入式与只读根文件系统嵌入式设备的根文件系统通常是只读的 squashfs加一个 tmpfs 挂载到/tmp、/var/run这类需要写的地方。这样做的原因很实在Flash 擦写次数有限根文件系统只读能避免意外写坏掉电也不会损坏。需要更新的分区用 ext4 或者 ubifs配合双分区 A/B 升级方案出问题还能回滚到旧版本。这个场景里有个容易忽略的点日志型文件系统在 Flash 上跑频繁的日志写入会加速磨损。要么用不带日志的文件系统要么把日志放到 tmpfs 上或者把常见的写目录全做成内存盘。设备量大的时候这个优化能显著降低返修率。7.4 桌面和移动硬盘省心优先桌面机其实不用纠结发行版默认什么就用什么。Ubuntu 系默认 ext4用了十几年工具链成熟出问题搜到的资料最多。移动硬盘如果要在不同系统之间来回插exFAT 或者 NTFS 反而比 ext4、xfs 更实用——毕竟 Windows 和 macOS 认不出来 ext4插上去只会提示需要格式化这个对话框千万别点。8. 几个不太写进文档、但很好用的经验8.1 备份和迁移时tar、rsync、dd 的行为差别很大dd是块级复制会把文件系统的空块一起搬过去200G 的盘哪怕只用了 10G也得老老实实传 200G而且目标设备必须不小于源设备。好处是完整还原包括所有元数据。tar和rsync是文件级只搬实际数据速度快、目标可以小但会丢掉一些细节稀疏文件的稀疏性、扩展属性、ACL、硬链接关系。我的习惯是同一台机器上做整盘镜像用dd跨机器迁移数据用rsync -aHAX --numeric-ids其中-H保留硬链接、-A保留 ACL、-X保留扩展属性。迁移完一定要抽查文件数量和关键目录权限尤其是有大量硬链接的备份目录漏掉-H会把硬链接展开成一堆独立副本空间和语义都变了。# 跨文件系统迁移保留权限、属性、硬链接 sudo rsync -aHAX --numeric-ids --infoprogress2 /src/ /dst/ # 迁移后对比文件数量做交叉验证 find /src -type f | wc -l find /dst -type f | wc -l8.2 改名、硬链接、跨盘移动的实际开销同一个文件系统内重命名文件几乎瞬间完成因为只改了目录项数据块没动。但跨文件系统移动就变成复制加删除大文件会很慢这是很多人疑惑为什么改个位置要等这么久的原因。硬链接只能在同一个文件系统内创建跨盘必然失败。备份工具如果不支持硬链接会把硬链接展开磁盘占用成倍增长。这也是为什么增量备份经常用hardlink方式做快照——同一个文件在多天的备份目录里共享数据块只有真正改动的部分才占新空间。8.3 新盘上线的固定动作清单最后分享一套我每次上新盘都会走一遍的流程能避开大部分低级问题确认设备名和容量lsblk看一遍别对着错盘操作。用parted分区并确认 4K 对齐写上分区表。如果是 RAID 或 LVM先算好 su/sw 或 stride/stripe-width。mkfs时按用途定 inode 比例、AG 数量、日志大小。写入/etc/fstab优先用 UUID 而不是/dev/sdX避免设备名漂移导致开机失败。先mount -a验证一次再重启测试别直接重启赌运气。挂载参数加上noatimeSSD 配上fstrim.timer。数据盘调低 ext4 保留块比例。第 5 条特别值得强调。我见过不止一次因为插了新硬盘导致设备名从/dev/sdb变成/dev/sdc开机直接进救援模式。用blkid查 UUID 写进 fstab这个问题就彻底消失了。文件系统这东西平时感觉不到它的存在一旦出事就是最麻烦的那类故障。与其在告警响起来的时候手忙脚乱地翻文档不如在格式化那一刻就把参数想清楚把挂载项配扎实。我个人最深的体会是别追新别抄网上的老参数把你当前负载的真实特征摸清楚——顺序写多还是随机写多大文件多还是小文件多会不会频繁快照回滚能不能接受断电丢几秒数据。这几个问题答完了ext4 还是 xfs 根本不是选择题答案自己就出来了。
机制)
