e4defrag -c 是判断 ext4 碎片程度最直接有效的命令，只统计 extent 分布，关注文件行末 contiguous 百分比（＜85% 且＞100mb 需关注）和挂载点 fragmentation factor（≥25% 且剩余空间紧张时考虑整理）。
e4defrag -c 是判断 ext4 碎片程度最直接有效的命令，但它不适用于 XFS 或 Btrfs；Linux 文件系统是否需要整理，取决于实际性能表现和空间使用率，而不是“看起来碎了就要整”。
怎么用 e4defrag -c 看文件或挂载点的碎片程度
e4defrag -c 不修改文件，只统计当前可访问文件的 extent 分布，输出里关键看两处：
- 每个文件行末的 contiguous 百分比：100.00% 表示完全连续；低于 85% 且文件 >100MB 时值得关注
- 挂载点汇总行的 fragmentation factor（不是百分比）：0–10% 基本不用管；≥25% 且剩余空间 执行前务必确认是 ext4：df -T /path，别在 XFS 上跑 e4defrag，会直接报 Operation not supported常见误操作：对正在写入的数据库文件执行 e4defrag -c /var/lib/postgresql/...，结果看到 extents: 0 或数值跳变——这不是碎片高，是文件被锁住、无法读取块映射
filefrag 能看到更底层的物理块分布，但要注意时效性
filefrag 输出里的 extents 数字反映该文件被分成几段物理存储，logical 和 physical 列能直观看出跳跃跨度（比如 logical 0→1024 对应 physical 123456→789012，中间隔了几万块）。
但它对活跃文件不靠谱：lsof +D /path 先查有没有进程正打开目标文件；若有，filefrag 返回的可能是旧快照，甚至因 page cache 未刷盘而显示“连续”，实际磁盘上已分裂
另外，filefrag 不区分文件类型：对稀疏文件（如 qemu-img create -f qcow2 创建的镜像）会把空洞也计入逻辑偏移，导致 extents 偏高，不能直接等同于真实碎片
XFS 和 Btrfs 根本没有“文件级碎片整理”这回事
XFS 的xfs_fsr 不是整理单个文件，而是后台扫描并尝试将小 extent 合并成大 extent —— 它只在空闲时运行，且效果依赖空闲空间是否足够连续；xfs_db -r -c "freesp -d" /dev/sdXN 才能看出空闲块是否碎成“芝麻粒”（大量 Btrfs 的 btrfs filesystem balance 更不是整理，它是重分布所有数据块到新 chunk，本质是重建局部索引，期间 I/O 压力极大；且必须确保有 ≥10% 空闲空间，否则 balance 会卡死在某一步三者共通陷阱：df 显示还有 5GB 空间 ≠ 整理工具能用。ext4 需要临时空间分配新 extent；XFS xfs_fsr 需要连续空闲区来合并；Btrfs balance 需要 chunk 重分配余量——这些“隐性空间需求”常被忽略，导致命令中途失败并报 No space left on device
真正该优先做的，是释放空间而非整理碎片
碎片影响性能的前提是：磁盘使用率长期 >85%，且负载以大量随机小文件读写为主（比如邮件服务器、日志归档目录）。多数情况下，journalctl --vacuum-size=200M、apt clean、find /var/log -name "*.log.*" -mtime +30 -delete 释放出 5–10GB，比跑一小时 e4defrag / 更有效。
容易被跳过的检查项：
-
df -i查 inode 是否耗尽——碎片工具本身也会创建临时 inode，若 inode 满了，e4defrag直接失败 -
lsof +L1找“已删未释放”文件——这类文件占着磁盘却不显现在du里，清掉它们可能立刻腾出几十 GB -
stat -f -c "Available: %a * %S bytes = $(echo $(stat -f -c '%a*%S' .)/1024/1024/1024 | bc -l) GB" .算真实可用字节数，比df -h更准（考虑预留空间）
最后提醒一句：别对根分区在线跑全盘 e4defrag /。它会扫描 /proc、/sys 下的虚拟文件，报一堆 Permission Denied，还可能卡住 systemd-journald 的日志写入——真要整，限定目录，比如 e4defrag /home/user/Videos
