ext4 比 ext3 快很多，关键在于用 extents 替代间接块映射并引入延迟分配：extents 减少元数据开销和寻道，延迟分配优化块布局、降低碎片，尤其提升顺序写性能。
ext4 为什么比 ext3 快很多？关键在 extents 和延迟分配
ext4 的性能跃升不是靠堆参数，而是底层数据结构的重构。最核心的改变是用 extents 替代了 ext3 的间接块映射。一个 1GB 的连续文件，在 ext3 中可能需要上万个块指针来描述；而在 ext4 中，往往只需几个 extent 条目——每个 extent 能描述最多 128MB 的连续物理块（按 4KB 块大小计算）。这直接减少了 inode 元数据体积、降低了磁盘寻道和内存开销。
配合 delayed allocation（延迟分配），文件系统不急着落盘分配块，而是等到数据真正刷入 page cache 后、写入前一刻才统一决策。这样能更优地聚合同一文件的数据块，显著减少碎片，尤其对顺序写场景（如日志、数据库 WAL、视频转码）效果立竿见影。
- 注意：
delayed allocation在异常断电时有极小概率导致未 sync 的数据丢失（但不会损坏已提交数据），这是它换来的性能代价 - 禁用它可用挂载选项
delalloc=0，但一般不建议，除非你在做严格一致性测试 -
extents是默认启用的，无法关闭；格式化时加-O ^extents会强制退回到 ext3 兼容模式（不推荐）
单文件和文件系统容量到底有多大？别被“1EB”误导
ext4 官方标称支持最大 1EB（1,152,921.5 TB）的文件系统和 16TB 单文件——但这只是理论上限，实际受限于内核版本、块大小（block size）、以及是否启用 64bit 特性。
关键点在于：即使你用 mkfs.ext4 -b 65536 创建了 64KB 块，单个文件仍受 inode 中 extent 数量限制（默认最多 480 个 extent 条目）。要突破 16TB 单文件，必须在格式化时显式启用 64bit 特性：mkfs.ext4 -O 64bit /dev/sdX。否则即使文件系统本身够大，open() 或 ftruncate() 到超限位置会直接返回 EFBIG 错误。
- 检查是否启用 64bit：
dumpe2fs -h /dev/sdX | grep "Filesystem features"，输出含64bit即生效 - 老内核（如 3.10 之前）可能不识别 64bit ext4，挂载会失败并报
Unknown filesystem type - 不要指望用
fallocate()直接分配 20TB 空间——若未启用 64bit，调用会静默截断或失败
挂载时哪些选项真影响日常使用？noatime 和 data=ordered 是底线
绝大多数服务器场景下，只需两个挂载选项就足够平衡性能与安全：noatime 和保持默认的 data=ordered。
noatime 禁止更新文件访问时间戳，避免每次 read() 都触发元数据写入，对频繁读取小文件的场景（如 Web 服务、Python 导入）提升明显。而 data=ordered（ext4 默认）保证文件数据在对应日志提交后再写入数据区，既避免 ext3 writeback 模式的潜在不一致风险，又比 journal 模式轻量得多。
- 慎用
data=writeback：它允许数据在日志提交前写入，虽快但断电后可能看到“新文件内容 + 旧文件长度”的错乱状态 -
barrier=1（默认）应保留，关掉它在某些 RAID 卡或 NVMe 上可能导致日志损坏 -
commit=60可延长日志提交间隔，降低 sync 频率，但增加最多 60 秒数据丢失窗口
遇到 fsck.ext4 卡住或报 “Group descriptors corrupted” 怎么办？
这类错误通常不是硬件问题，而是超级块（superblock）或组描述符（group descriptor）校验失败。ext4 默认每组备份一份超级块，但组描述符只有一份主拷贝——一旦损坏，fsck 就无法定位 inode 表或块位图。
先别急着跑 -y 强制修复。用 e2fsck -n /dev/sdX（只读检查）确认是否真损坏；再用 dumpe2fs -h /dev/sdX 查看备份超级块位置（如 32768、98304…），尝试指定恢复：e2fsck -b 32768 /dev/sdX。若仍失败，可能是组描述符损坏，这时需用 mke2fs -n（dry-run 模式）模拟重建布局，再人工提取关键信息。
- 定期备份超级块：
dumpe2fs /dev/sdX | grep -i "superblock backup"，把输出的位置记下来 - 避免在 fsck 过程中断电或 kill 进程，这是人为制造元数据损坏的最快方式
- SSD/NVMe 上启用
metadata_csum（mkfs 时默认开启）能提前发现校验错误，比等 fsck 报错更早干预
extents 有 fallback 到传统块映射的兜底，journal 支持在线迁移，flex_bg 自动适配大容量设备。真正容易翻车的，往往是绕过这些设计、硬去压榨边界值——比如在没开 64bit 的情况下硬试 18TB 文件，或在无 UPS 的环境里关 barrier + writeback。 
