btrfs因cow机制导致io放大、与o_direct冲突、快照压缩增加不可控路径、不支持对齐写入、修复工具仅限离线且高风险、raid下延迟毛刺显著，故应避开；xfs适合大文件高并发写，需调优agcount/log参数；ext4适合小文件oltp，需谨慎配置journal和barrier。
btrfs 不适合生产数据库，ext4 和 xfs 才是实际可选项；其中 xfs 在大并发写入、大文件场景下更稳，ext4 则在小文件多、sync 频繁的 OLTP 场景里更容易调优。
为什么 btrfs 在数据库场景下要主动避开
btrfs 的写时复制（CoW）机制在数据库随机写密集场景下会放大 IO 放大效应，尤其当 metadata 压力高时，btrfs filesystem usage 显示碎片率飙升，btrfs balance 又无法在线低开销执行。MySQL 的 innodb_flush_method=O_DIRECT 与 btrfs 的 CoW 存在语义冲突，曾导致大量 Transaction log write failure 错误；PostgreSQL 的 WAL 写入在 btrfs 上也出现过非原子提交问题。它的快照和压缩功能看似诱人，但数据库层自己已有 WAL + 备份链路，这些特性反而增加不可控路径。
- 不支持
O_DIRECT对齐写入（内核 6.1+ 仍存在部分绕过 CoW 失败的情况） -
btrfs check --repair是只读模式下的“最后手段”，线上库一旦触发几乎等于停机抢救 - RAID1/5/6 模式下元数据校验与重映射逻辑复杂，IO 延迟毛刺比 ext4/xfs 高 2–5 倍（实测 pgbench TPS 波动超 30%）
xfs 在高吞吐写入场景下的关键配置点
xfs 对大文件追加写、顺序写优化充分，InnoDB 的 ibdata1 或 PostgreSQL 的 base backup 目录放在 xfs 上，xfs_info 输出中的 agcount 和 agsize 直接影响并行写性能。默认 mkfs 参数在 NVMe 盘上容易造成 AG 竞争，必须手动调大。
- 格式化时加
-d agcount=32（NVMe）或-d agcount=16（SATA SSD），避免 AG lock 成为瓶颈 - 挂载参数必加
nobarrier,logbufs=8,logbsize=256k（仅限有掉电保护的存储），否则日志刷盘延迟突增 - 禁用
inode64—— 虽然它让 inode 分布更均匀，但在数据库频繁创建临时表时反而引发跨 AG 查找开销 -
xfs_growfs支持在线扩容，但xfs_db -r -c "frag" /dev/xxx要定期查碎片，>20% 就得考虑 dump-restore
ext4 在强一致性要求下的调优边界
ext4 的 data=ordered 是 MySQL 默认且最稳妥的模式，它确保数据页落盘早于日志提交，但会拖慢写入吞吐。如果你用的是 Percona Server 或 MariaDB 并启用了 innodb_doublewrite_log_encrypt，那么 barrier=1 必须保留，否则 doublewrite page 可能损坏。
- 禁用
journal=async—— 它会让 journal 写入异步化，但数据库 crash 后 recovery 失败率显著上升 -
tune2fs -o journal_data_writeback /dev/xxx看似提升性能，实则绕过 journal 校验，PG 的 WAL 归档可能静默出错 - SSD 上建议开启
discard（但需配合fstrim.timer定期运行），否则 long-term 运行后df与du差值持续扩大，影响空间预估 -
e2fsck -f -y可强制检查，但必须 umount；线上库做这个动作前，先确认/proc/mounts中无ro,errors=remount-ro类似降级策略
别忽略 mount 选项与数据库 sync 行为的隐式耦合
同一个文件系统，mount -o defaults 和 mount -o noatime,nodiratime,commit=5 对 pgbench 结果影响可达 18%。MySQL 的 sync_binlog=1 + ext4 的 barrier=1 组合，本质是两次强制刷盘；而 xfs 的 logbsize 实际控制了这“一次”刷多少日志块——不是越大越好，256k 是 NVMe 下实测拐点。
- 所有数据库都应禁用
atime，但relatime在某些内核版本（如 5.4.0-105）下仍会触发额外元数据更新 -
commit=值设为 5（秒）对 xfs 无效，xfs 只认自己的 log buffer 刷盘节奏；ext4 才真正响应这个参数 - 容器环境要注意：若用
overlay2+ ext4 宿主机，docker run --storage-opt size=创建的 devicemapper 卷，底层仍是 ext4，但 metadata 更新路径多了一层，fsync()延迟比裸盘高 0.8–1.2ms
文件系统不是“装好就完事”的组件，数据库 workload 一变，xfs_info 和 dumpe2fs 的输出就得重看一遍；尤其是升级内核或换 SSD 型号后，原来有效的 agcount 或 stride 参数很可能变成性能陷阱。
