ext4 调优需按负载选参：data=ordered 保一致性，data=writeback 提性能但有丢数风险；barrier= 1 必开；小文件场景格式化时用 mke2fs -i 4096 增 inode；SSD 必加 noatime,nodiratime，TRIM 慎用 discard；journal 大小依吞吐调整，512MB 起；一切以 iostat 和 dmesg 监控为依据。
ext4 挂载参数怎么选才不拖慢 IO 又避免丢数据
默认挂载的 ext4 在多数场景下够用，但一旦有数据库写入、日志轮转或高并发小文件操作，就容易出现延迟抖动或意外断电后文件系统损坏。关键不是堆参数，而是按负载类型做取舍。
-
data=ordered（默认）平衡性最好：元数据强制日志，数据页异步刷盘，既保一致性又不严重拖慢吞吐 - 若应用自己做了双写或 WAL（如 PostgreSQL、RocksDB），可改用
data=writeback提升写性能，但断电可能丢失未刷盘的数据页 -
barrier=1必须保留（除非你关了磁盘写缓存且确认硬件无电池保护），否则日志屏障失效会导致日志与数据不一致 - 避免盲目加
commit=60：延长提交间隔虽降低日志 IO 频次，但会增加崩溃后回滚量和恢复时间
inode数量不足导致“no space left on device”但 df -h 显示还有空间
这是典型 inode 耗尽，常见于大量小文件（如容器镜像层、npm/node_modules、日志切片）。df -i 一看便知。格式化时没预留足够 inode，后期无法扩容。
- 创建文件系统时用
mke2fs -i 4096（每 4KB 分配一个 inode），比默认的-i 16384更适合小文件密集型场景 - 已有文件系统无法增 inode 数量，只能迁移：用
rsync -aHAX备份，重新mke2fs，再恢复 - 临时缓解可用
tune2fs -l /dev/sdX1 | grep "Inode count"查当前总量，再find /path -xdev -type f | wc -l看是否接近上限
SSD 上禁用 atime 更新和启用 TRIM 的实际效果
禁用 atime 几乎零成本且必开；TRIM 则需确认路径全 栈支持（固件、驱动、RAID 卡、文件系统挂载选项），否则不仅无效还可能引发异常。
- 挂载时加
noatime,nodiratime：避免每次读都触发磁盘写，对频繁 stat 的服务（如 Web 服务器、打包 工具）明显降低 IO 压力 -
discard挂载选项只建议用于直连 NVMe/SATA SSD；若走 RAID 卡或 虚拟化 层，应改用定期fstrim -v /（加入 cron） - 检查 TRIM 是否生效：
lsblk -D看DISC-GRAN和DISC-MAX是否非零；再运行sudo hdparm -I /dev/sdX | grep TRIM
journal 大小设置不当引发卡顿或浪费空间
ext4 日志默认 128MB，对机械盘够用，但对高吞吐 SSD 或大内存机器，过小会导致频繁日志循环覆盖、阻塞事务；过大则占用过多连续空间且恢复慢。
- 观察日志压力：
dmesg | grep -i "ext4.*journal"若频繁出现journal too small或journal full，说明需要调大 - 调整命令：
tune2fs -J size=512M /dev/sdX1（最大建议不超过 2GB） - 注意 journal 必须位于同一块设备上，跨设备（如放到另一块 SSD）需用
-J device=/dev/sdY1，但会引入额外 IO 路径依赖 - 如果使用 LVM，journal 放在 thin pool 上可能导致元数据竞争，此时建议保持默认或略增大，不盲目堆大
tune2fs -l /dev/sda1 | grep -E "(Journal|Inode size|Block count)" 实际调优永远从监控出发：先看 iostat -x 1 的 %util、await、svctm，再结合 cat /proc/mounts 和 dmesg 找线索。没有通用最优解，只有当前 workload 下最不坏的选择。
