磁盘与文件系统：从爆盘事故到选型、分区与运维排查

1. 从一次“爆盘”事故聊起：为什么磁盘与文件系统值得单独花时间研究

1.1 事故经过：共享存储被打满的真实场景

前年我们内部一台承担日志汇聚和临时文件交换的服务器出了问题，现象很奇怪：所有服务还在运行，但新日志写不进去，临时目录里的文件也创建不了，部分功能接口直接超时。一开始大家都怀疑是程序有Bug，查了两天才发现根本不是代码问题，只是那块数据盘的系统保留空间用完了。df -h看挂载点使用率是100%，而实际文件加起来并没有占满多少，罪魁祸首是几个不断增长又没有清理策略的日志文件，外加一堆临时大文件的残留。

这件事给我的教训特别深。磁盘和文件系统平时没人关心，一旦出了问题，往往就是服务不可用的级别。你要临时扩容，可能要关机、可能要卸载分区、可能牵动一大堆业务；你要删文件，还得先确认有没有进程在占用；你要格式化，得提前想好数据备份。这些操作和日常写代码完全是两种节奏，稍微手一抖，损坏的就是整个数据面。

所以这个标题看着朴素，但里面值得讲的东西其实非常多。磁盘解决的是“数据以什么物理形式存在”，文件系统解决的是“数据以什么逻辑结构被管理”。大部分开发者熟悉的是网络协议、数据库事务、缓存策略，但对ext4和NTFS的区别、对 inode 耗尽、对分区对齐、对挂载参数这些底层细节没什么概念，恰恰是这些细节决定了系统的可靠性和高危场景下的存活率。

1.2 文件系统决定的不只是“能存多少”

很多人的第一反应是，文件系统不就是决定了能存多大文件、能分多少个区吗？这个理解太粗了。文件系统做的事情，比你想象的多得多。你可以把磁盘想象成一个大货仓，物理上就是一排排货架。文件系统则是仓库管理员加台账系统，它要负责记录每件货放在哪个货架、货物被谁借走、货架上的哪些区域已经满、货物挪动时怎么更新台账、如果突然断电台账会不会乱。

举几个实际例子：ext4 在向磁盘写入数据时，会先更新日志（journal），再真正写数据，这样一旦断电，重启后可以通过日志恢复一致性，代价是写性能会受一点影响。XFS 的设计则倾向于大文件、高吞吐，它同样有日志机制，但在并发写入和多线程场景下表现更好。Btrfs 则是写时复制（CoW）设计，支持快照，但历史上出现过一些性能问题，而且很多生产环境默认并不选择它作为主文件系统。

这些差异不是纸上谈兵，直接决定了同一个应用代码跑在不同文件系统上的表现。我见过一个内部的数据导入任务，在某台机器上需要三四个小时，换到另一台相同配置但文件系统不同的机器上，时间缩短了将近四成。排查到最后，就是文件系统的元数据操作方式和日志策略不同导致的。你说文件系统重不重要？它几乎决定了底层性能的上限和灾难恢复的难度。

2. 选型之争：日常场景里到底该用哪个文件系统

2.1 以 Linux 场景为主的选型对比

先说最常见的 Linux 服务器场景。如果你是想选一个不出错、稳定、资料多的文件系统，ext4 依然是默认安全感最高的选择。它足够成熟，格式化工具强，fsck的修复能力经过了极长时间验证，而且几乎所有发行版都原生支持。对于一般业务盘、日志盘、数据库备份文件，ext4 都是稳的。

XFS 则更适合大文件、大容量、高并发写入的场景。它的元数据设计偏向扩展性，格式化一个几百TB的存储池，XFS 比 ext4 更从容。很多文件服务器和对象存储内部的数据盘愿意选 XFS，就是看重它在超大容量下的表现。但 XFS 有一个让新手头疼的地方：它不支持缩容，只能扩大分区，不能无损缩小。这意味着如果你习惯了“把分区弄小了重新再来”，在 XFS 上你会比较难受。

Btrfs 的好处在于快照和校验和，能做文件级别的校验，还支持在线扩容、缩容，设计理念非常现代。但它的 CPU 开销更高，碎片管理相对复杂，一些硬件或特定负载下会出现性能抖动，不太适合作为对延迟极敏感的核心数据库存储。我个人的建议是，Btrfs 适合作为个人实验和研究用途，或者用来放一些不太需要极端性能但需要快照保护的容器存储目录。生产环境的数据库数据目录，还是老老实实选 ext4 或 XFS。

2.2 跨平台与桌面的方案：NTFS/exFAT 以及双系统踩坑

桌面和移动存储环境又是另一套逻辑。我经常看到有人拿一个移动硬盘，在 Winodws 和 Mac 之间来回拷贝资料，格式选得不对，麻烦不断。如果用 NTFS，Windows 下很舒服，但 macOS 默认只读不能写，还要折腾 NTFS 驱动，用了第三方驱动还要担心内核版本升级后失效。如果移动硬盘只在两台电脑之间拷贝大文件，建议直接格式化成 exFAT，两边都能读写，不需要额外驱动。

但 exFAT 不是万能的。它没有复杂的日志机制，在拷贝过程中如果突然断电或拔插，文件很容易损坏。我自己的习惯是：移动硬盘只放一些非关键性的文件，比如软件安装包、影视剧、临时项目交换文件。重要的照片、资料件一定要在另一块盘或网盘里有备份，因为你不知道哪一次拔插就会带来意想不到的惊喜。

还有一个非常容易踩的坑是 U 盘被格式化成 ext4 后，在 Windows 上完全读不出来。某个周末我帮人拷贝一个系统安装镜像，对方把 U 盘格成了 ext4，插入 Windows 机器直接不识别，连重新格式化都要先通过 Windows 磁盘管理删分区。这种问题看似低级，但非常普遍，跨平台传输之前一定先确认接收方使用的操作系统。

2.3 我对 ZFS 和硬件 RAID 保留的意见

ZFS 在圈子里口碑极好，数据校验能力、快照能力、存储池管理都非常强，很多人一接触就觉得相见恨晚。但我对个人和小团队直接上 ZFS 一直持保留态度。原因有两个，一个是内存消耗非常夸张，ZFS 的 ARC 缓存机制会自动吃大量内存，配置不当的话反而是性能负担；另一个是故障替换的复杂度比常规文件系统高很多，如果不对 ZFS 的导入/导出机制非常熟悉，出问题以后光是把存储池恢复起来就可能要折腾好几天。

硬件 RAID 也一样，市面上入门级硬件 RAID 卡的性能其实可以被软件层完胜，而且一旦卡坏了，换个同型号的卡可能都起不来，这个教训我踩过。对于大多数中小规模业务，我更倾向的思路是：用简单的软件 RAID 或者直接靠备份策略来兜底，配合管理层清晰的冷备、热备方案，比迷信硬件 RAID 要现实得多。

3. 分区、格式化与挂载：实操清单和关键参数

3.1 分区表选择：GPT vs MBR

很多人装系统时选分区表类型是凭感觉的，其实这东西非常基础，却特别关键。MBR 也就是传统主引导记录，引入时间早，单盘最大只认到 2TB，而且只能分四个主分区，再加上启动机制是直接用引导扇区代码引导系统，可靠性一般。GPT 则是新一代分区表标准，支持超大容量，分区数量基本不受限制（Windows 下默认 128 个），而且磁盘尾部和头部都有分区表备份，安全性更好。

我自己的习惯是，只要不是需要兼容非常老的设备，一律用 GPT。有一个容易忽略的点是：在 UEFI 环境下，如果磁盘还是 MBR 分区表，引导时会多一道 CSM 兼容逻辑，现代主板默认优先 UEFI，可能导致系统盘识别异常，反而增加故障排查难度。所以新装的机器我建议直接 GPT，不要给自己埋雷。

3.2 分区对齐为什么重要

分区对齐的“对齐”是指分区起始扇区要和底层物理扇区、SSD 的页对齐。传统硬盘扇区 512 字节，后来高级格式化改为 4K 物理扇区，SSD 的读写单元又是按页处理的。如果分区起始位置没有对齐到 4K 边界，每次读写可能跨越两个物理单元，底层放大效应严重。

查看是否对齐可以这样验证：先lsblk找出设备名，再用/sys/block/sdX/queue/alignment_offset或fdisk -l观察 Start 扇区数值。在分区时，新版fdisk默认从 2048 扇区开始，这个值对应 1MiB 对齐，基本不会有问题。但我见过不少老旧的装机脚本，还写死从扇区 63 开始分区，遇到 4K 扇区的盘就会异常缓慢。之前帮人排查一块 SSD 上启动的虚拟机特别慢，I/O 吞吐低得吓人，最后发现就是某云镜像创建启动盘时对齐参数不对，重做分区后速度明显回升。

分区对齐这个事看着小，但对磁盘寿命和性能影响不小。新盘分区的时候一定要留意工具版本和默认对齐策略，别用太老的工具。

3.3 格式化命令与预留空间

格式化并不是简单地执行一下mkfs就完事了，有非常多的参数值得认真对待。以 ext4 为例，-m参数控制预留块比例，默认是 5%。这个百分比本意是给 root 用户预留空间，防止普通用户写满后系统本地连 root 都无法执行维护任务。但对于一块 4TB 的数据盘，5% 意味着 200GB 直接不可用，对存储密度要求高的场景太浪费了。我通常会在格式化时把预留比例调成 1% 甚至 0.5%，比如：

mkfs.ext4 -m 1 /dev/sdb1

还有块大小参数-b。小文件多的地方用 4K 默认值没问题，如果知道这个目录主要是存大于 64KB 的大文件，可以适当调大块大小，减少元数据占用。但要清楚，块大小一旦固定，之后改起来非常麻烦，格式化之前就要规划好。

XFS 格式化时同样有关键参数需要了解，比如-d指定数据区布局选项，-i设置 inode 大小和密度。默认 inode 分配通常够用，但如果你计划长时间存放海量小文件，可以把每个 inode 的字节数调低，比如：

mkfs.xfs -i maxpct=5 /dev/sdb1

3.4 挂载参数与 noatime 的取舍

挂载参数里最实用但最常被忽略的就是noatime。默认情况下，系统每次读取文件都会更新 atime，也就是访问时间，这会产生大量的元数据写入。对 SSD 来说是无谓的写入放大，对机械硬盘来说是无谓的寻道开销。除非你的应用确实依赖 atime 判断文件最近被阅读的时间，否则直接挂载为noatime好处更多。

mount -o noatime /dev/sdb1 /data

如果希望在/etc/fstab里固化，可以这么写：

/dev/sdb1 /data ext4 defaults,noatime 0 2

这里最后一个数字 2 代表启动时进行磁盘检查的优先级。很多人习惯写 0 跳过检查，图省事，但这样做一旦异常断电，下一次启动时文件系统的异常可能不能及时被发现。我个人会保留 1 给根分区、2 给普通数据分区，让系统定期做一致性检查。

另外，临时目录和频繁写入的小文件目录，可以考虑用tmpfs映射一部分到内存，减少真实磁盘的压力。但要注意，tmpfs 是易失性的，重启后就什么都没有了，只能放临时缓存类内容，绝不能放数据库文件。

4. 日常运维中最容易踩的六个坑

4.1 df 和 du 看到的容量不一样

遇到过很多次这样的情况：明明du -sh /data看着只有几百 GB，但df -h /data却显示已经用了 90% 以上。排查这个问题完全靠经验。一个典型原因是，有进程已经将某个文件删除了，但文件句柄仍被进程持有，空间不会立即释放；另一个原因是某个目录被挂载点覆盖了，实际大量文件写在隐藏的挂载点下层目录中，du从当前挂载点统计不到。

可以这样排查：先看系统的打开文件句柄里有没有 deleted 状态的记录：

lsof +L1 | grep deleted

如果找到被删除但仍然打开的文件，重启对应进程或服务，空间一般就会释放。对于挂载点覆盖的问题，可以先临时取消挂载或者换个角度统计：

mount --bind /some/place /tmp/debug_dir du -sh /tmp/debug_dir

这种做法用起来很顺手，能快速定位是不是目录被挂载覆盖了。

4.2 inode 耗尽：还有空间，但就是创建不了文件

文件系统在存储文件内容之外，还要为每一个文件或目录建立元数据节点，这个节点就是 inode。很多运维事故是 inode 不够用了：df -h看着还有 30% 空间，但mkdir直接报错，提示空间不足。其实数据块还有余量，只是 inode 表满了。

排查命令是：

df -i

如果 IUse% 接近 100%，就说明 inode 耗尽。常见原因是某个目录里堆积了几十万个临时小文件，比如面向用户的网盘系统的临时缩略图目录、交易对账文件目录。解决办法也不复杂，把历史小文件批量压缩打包并移动到另一块盘，或者设置定时清理策略。但根治还是要从一开始就规划 inode 密度，比如 ext4 可以指定-i参数控制多少字节分配一个 inode：

mkfs.ext4 -i 8192 /dev/sdb1

这个参数的实际含义要根据文件和目录数量来核算，别拍脑袋调太小或太大。

4.3 文件系统层损坏：superblock 和 ext4 的修复

异常断电、强制重启、不安全的硬盘拔插，都可能让文件系统的元数据区域处于不一致状态。Linux 正常情况下重启会自动做一致性检查，但如果检查没做完系统就又被强制断电，问题就会叠加。

遇到文件系统挂不上或者报结构错误时，第一原则是不要再挂载，更不要直接写数据，先把当前状态备份出来，再执行修复。修复 ext4 文件系统通常用：

# 不要直接在挂载状态下运行，需要先卸载或至少使用只读模式 fsck.ext4 -f /dev/sdb1

如果连主 superblock 都损坏，fsck找不到有效元数据，可以查看备份 superblock 的位置：

dumpe2fs -h /dev/sdb1 | grep superblock

然后用备份的 superblock 打开文件系统去恢复数据。这里想提醒一句：越是着急越不要用fsck -y无脑自动修复，很多情况下自动修复可能导致部分目录被移动到lost+found中，你要自己去找回来。如果数据极其重要，不如先用dd把整块分区镜像备份到另一块盘上，再在镜像上做恢复尝试。

4.4 稀疏文件、预分配与空洞

稀疏文件这个词对很多人来说有点陌生，但问题其实很常见。某些程序在创建大文件时会先通过truncate或fallocate预分配一个很大的空间，这中间可能并不会有真正的数据写入。比如：

truncate -s 100G /data/bigfile.img

执行完以后ls -lh看到文件大小是 100G，但du -h一看实际占用的块非常小。这就是稀疏文件，逻辑大小和实际占用完全不同。好处是创建快、不占空间，坏处是很多压缩备份工具会读这个文件的全部逻辑内容，导致备份过程慢、备份结果巨大。还有一些软件会在文件尾部写入一个字节，但把逻辑大小设置成巨大，结果复制工具白白读了几百 GB 的空洞数据。

排查可以用du和ls -l对比大小差异，也可以用filefrag查看实际分配情况。如果你要发送或传输这类文件，最好先让目标程序知道这是一个稀疏文件，或者直接拷贝成紧凑格式。

4.5 快照与删除顺序：LVM/文件系统快照的误用

用 LVM 做快照备份是非常常见的方案，但很多人没搞懂快照的原理。LVM 快照并不是在建立的那一刻把整个数据区复制一遍，它采用的是写时复制机制：建立快照后，如果原始数据区有块要修改，才先把旧数据复制到快照区。这意味着快照刚建完非常节约空间，但随着原始卷不断变化，快照区占用会持续增长。

有个真实教训：某次要清理一个数据库目录，先做了 LVM 快照打算慢慢归档，然后在原始卷里删了大批数据。几天后快照卷因为空间增长被打满，直接失效，等于备份白做。正确的操作顺序是先确认快照卷大小可以承载整个变化量，并且在快照保留期间尽量避免对原始卷做大规模修改，或者及时将快照数据整体导出到另一块磁盘再删除原始数据。

4.6 快速格式化并不清数据，以及数据恢复基本方法

快速格式化在 Windows 和 Linux 上做的事情都差不多，只是重建文件系统结构，比如清除文件系统的元数据、重新生成根目录和 inode 区域。数据本身并没有被覆写，扇区里还是原来的0和1，所以市面上很多数据恢复软件能找到被“删除”的文件。

如果误删了文件，第一时间应停止向被误删分区写入任何数据，挂载为只读，然后用恢复工具扫描分析。Linux 下可以用testdisk和photorec这套组合，前者用于恢复分区结构和误删目录，后者用于按文件特征抽取文件内容。恢复效果好不好取决于误删后是否立刻发生了大量写入、文件是否碎片化严重。如果是 SSD，因为 TRIM 机制的存在，删除后的数据块可能会被设备自动擦除，恢复难度更大。

所以文件系统层面的“删除”从来不是真正删除。这也提醒我们，安全删除必须使用专门的擦除工具有意义，否则只是把指针标记为可写而已。

5. 故障排查实用现场与处置顺序

5.1 定位阶段：先看容量、inode、进程占用

真正遇到故障时，保持冷静并遵循固定的排查顺序特别重要，不然容易东一榔头西一棒子，浪费了大量恢复时间。我的习惯是这样：

第一步，先看容量。执行df -hT列出所有分区的文件系统类型、总大小、已用、可用、挂载点。没有-T参数的时候看不到文件系统类型，排查跨平台问题时会多费周折。如果某个分区使用率超过 95%，基本可以确定为空间紧张。

第二步，看 inode。执行df -i关注 IUse% 是否接近 100%。这一步往往可以快速判断是不是小文件过多的问题。

第三步，查找被删除但仍在打开的文件句柄。执行lsof +L1 | grep deleted，如果有多行结果，说明有进程长期持有某些已删除文件的句柄。这个时候就算你在磁盘上把数据清空了，空间也释放不了。

第四步，定位实际占用目录。这个要从根目录一层层往下找：

du -h --max-depth=1 /data du -h --max-depth=1 /data/* | sort -rh | head -20

找到最大的目录后再深入，直到定位具体的文件。整个过程不用太久，但要先有固定的习惯，不能着急乱删。

5.2 处理阶段：清理、扩缩容与安全卸载

定位到罪魁祸首以后，区分两种情况。如果是日志类文件导致的空间不足，可以直接清空文件而不是删掉，比如：

> /var/log/xxx.log

使用清空的方式有一个好处，正在写该文件的进程不会因为文件被删除而失去句柄，不会产生新的异常。如果是临时文件导致的，也需要先确认没有进程正在使用，再执行删除。

空间不足且需要扩容时，优先考虑是否有空闲分区可以扩展到当前逻辑卷。xfs 可以扩：

lvextend -L +100G /dev/vg01/data xfs_growfs /data

ext4 可以扩：

lvextend -L +100G /dev/vg01/data resize2fs /dev/vg01/data

但缩容是另一回事了。ext4 虽然可以缩，但必须先卸载分区、做文件系统检查、缩文件系统、再缩逻辑卷，整个过程风险很高，线上的生产环境建议不要做缩容。实在需要调整分区布局，最稳的办法还是把数据迁走，重建逻辑卷，再迁回。

安全卸载也是有讲究的。如果磁盘上还有进程访问，执行umount会报错 target is busy。这时候可以用lsof找到占用进程，也可以直接fuser -vm /data，找到 PID 后让业务方确认再停进程。常规做法是先停写、再执行sync强制落盘，最后umount，不要上来就强制卸载。

5.3 SSD 和机械盘混杂环境下文件系统层面的注意

SSD 普及以后，TRIM 机制对文件系统维护产生了新变量。TRIM 可以让 SSD 在删除数据时将对应的闪存块标记为无效，方便垃圾回收利用。如果用df看到容量足够但磁盘速度越来越慢，就可能是没有定期执行 fstrim。

查看系统支不支持自动 trim 和具体操作可以这样：

systemctl status fstrim.timer fstrim -v /data

如果没有启用定时任务，可以手动周期执行。但要注意，某些文件系统和 RAID 卡组合下 TRIM 不一定能被透传，而且大多数国产 SSD 对 TRIM 的支持细节并不透明，所以重要数据依然要按传统方式做备份，不要把所有希望寄托在单块盘的健康指标上。

机械硬盘这块，文件系统层面的重点是减少随机写入和碎片。如果数据集是顺序读写的流式数据，XFS 或者 ext4 大块参数是比较合适的选择；如果数据集是大量随机小 IO，机械盘再折腾也就那样，尽早考虑换 SSD 才是正解。日志型文件系统在机械盘上一般会让写入更平滑一些，但相应的元数据开销也更高，需要根据实际负载做取舍。

6. 故障排查速查表和一些关于备份的心里话

把上面提到的核心排查动作整理成一个速查表，方便大家在实际出问题的时候对照着处理：

这表里每一条背后都是真实的故障案例，不是凭空编出来的理论。

关于备份，我想多说几句。文件系统越复杂，理论上带来便捷的同时也在增加运维难度。无论你选择了 ext4、XFS 还是 Btrfs，要知道它们都只是工具，数据安全的核心永远是多副本和长期验证的恢复流程。文件系统层面的快照再厉害，整块盘物理损坏时一样什么都救不回来；RAID 卡再好，不测试定期恢复也是一纸空文。

我个人建议中小团队至少准备两条独立的备份途径：一条是异机同步，一条是归档介质离线放好。归档介质不需要很频繁地全量更新，但至少每周把核心数据拉一个全量副本出来。磁盘和文件系统是最后一道防线，你要做的不是让这道防线变成大坝，而是让它变成日常运维里最安静、最可靠的那一层基础设施。多花点时间读懂日志、看懂容量趋势、摸清文件系统的行为边界，比什么都重要。