XFS是由Silicon Graphics开发的高性能64位日志文件系统，从CentOS 7开始成为RHEL系的默认文件系统，在大数据、媒体存储、数据库等场景中被广泛使用。它天生支持大容量卷、高并发I/O和在线扩容，但默认配置只追求通用性，并非针对特定负载最优。同样的硬件，挂载参数和格式化选项设置不同，吞吐量可能相差数倍。本文将从挂载参数、格式化规划、日志与内存配置三个层面，详细讲解XFS性能调优的实践方法。
一、挂载参数调优：最容易见效的一步
挂载参数是XFS调优中最先应该处理的部分，因为它不需要重新格式化，改完/etc/fstab重新挂载即可生效，风险低、收益直接。首先是访问时间相关的参数。默认情况下，每次读取文件XFS都会更新atime（访问时间戳），这在高读取频率的场景下会产生大量无用的元数据写入。对于绝大多数服务器场景，atime几乎没有业务价值，建议直接加上noatime参数，它会同时覆盖nodiratime的行为，一次配置解决文件和目录两类时间戳更新。
其次是日志同步相关的参数。delaylog在较新的内核中已经是默认行为，它将多个元数据变更合并后再批量写入日志，能显著提升元数据密集型负载的性能，一般无需显式指定。而nobarrier这个参数需要特别谨慎：禁用屏障可以提升写入性能，但一旦掉电，文件系统可能损坏且无法通过日志恢复。除非你的存储设备本身带有电容保护的写缓存（比如企业级RAID卡配BBU），否则强烈不建议使用nobarrier。数据安全永远应该排在性能前面。
一个面向通用负载的推荐挂载配置如下：
# /etc/fstab 中的示例条目 /dev/sdb1 /data xfs defaults,noatime,inode64 0 0 # 临时重新挂载生效 mount -o remount,noatime /data # 查看当前挂载参数 cat /proc/mounts | grep xfs
其中inode64表示允许inode在文件系统全空间内分配，默认的inode32会优先在磁盘低位分配，当低位空间耗尽时可能出现"no space left on device"的假性报错，即便整个卷还有大量剩余空间。对于大容量卷，建议始终加上inode64。
二、格式化阶段的规划：mkfs选项决定长期性能
有些性能问题必须在格式化时解决，事后无法调整，比如分配组（Allocation Group）数量。agcount决定了元数据并发操作的并行度，XFS将卷划分为多个分配组，每个组有独立的空闲空间管理和inode分配，多线程并发访问时不同分配组可以互不干扰。默认值基于容量自动计算，但对于高并发的元数据密集负载（如海量小文件创建），可以适当增大agcount，例如一个4TB的SSD卷显式指定为32甚至64：
mkfs.xfs -f -d agcount=32 /dev/sdb1 # 针对RAID条带对齐的情况（RAID 10，条带64K，数据盘4块） mkfs.xfs -f -d su=64k,sw=4 /dev/sdb1 # 指定日志设备（使用独立SSD存放日志） mkfs.xfs -f -l logdev=/dev/sdc1,size=10g /dev/sdb1
su和sw这两个选项的作用是让XFS的数据块分配与底层RAID条带对齐。当XFS知道条带单元大小（su）和条带宽度（sw）时，它会尽量将连续大文件的写入按条带宽度对齐分布，避免RAID惩罚。这个对齐如果在格式化时没有设置，后续无法修改，只能重新格式化。如果你的设备是单盘或者普通云盘，则保持默认即可。
另外还要关注inode相关设置。mkfs.xfs -i size=512可以扩大inode容量，从而让更多扩展属性内联存储在inode中，减少一次额外的块访问，这对SELinux开启的环境（xattr较多）有帮助。而-m crc=0可以关闭元数据校验换取少量性能，但会失去数据完整性保护，一般不建议。格式化完成后，可以用xfs_info /data查看实际生效的参数，确认是否符合预期。
三、日志、内存与碎片管理
XFS的日志性能直接影响元数据操作的速度。日志写入本质是顺序小I/O，放在更快的介质上收益明显。对于数据库等元数据频繁变更的场景，可以把日志放到独立的NVMe设备上（即前面的logdev选项），主数据卷和日志各司其职。日志大小默认是卷大小的约0.4%，如果元数据写入非常密集，可以通过-l size=适当增大日志区，减少日志回刷频率，但注意日志越大，崩溃恢复时间也越长，需要权衡。
内存层面，XFS自身依赖页缓存，一般不需要专门调优，但有一个预读相关的注意点：XFS默认会根据文件系统的条带设置自动设定预读大小，如果mkfs时条带参数配置错误，可能导致预读不合理。可以用blockdev --setra手动调整块设备预读，例如大文件顺序读场景设为16MB（按512字节扇区计即32768）。虚拟机场景中，还要确认宿主机磁盘调度器，SSD建议设为none或mq-deadline，机械盘用mq-deadline或bfq，调度器不当会掩盖文件系统本身的优化效果。
最后是碎片问题。XFS对大文件采用延迟分配策略（delayed allocation），写入模式合理时碎片率很低，但长期高频随机写入后仍会出现碎片。检查命令是xfs_db -r -c frag /dev/sdb1，它需要先卸载文件系统（或以只读方式挂载），对在线环境可以用xfs_fsr进行碎片整理。与ext4不同，XFS支持在线整理，xfs_fsr逐文件重排数据块，可在业务低峰期执行：
# 查看碎片率（需卸载或只读挂载） xfs_db -r -c frag /dev/sdb1 # 在线碎片整理 xfs_fsr /data # 只整理单个文件 xfs_fsr -v /data/bigfile.dat
需要说明的是，碎片率在30%以内通常无需处理，盲目整理反而带来额外I/O压力。对于持续增长的写密集业务，更有效的方式是从源头规划：文件按时间或业务分目录存放、定期归档删除老文件、避免在同一目录堆积数百万个条目（XFS单目录虽然有目录哈希支持海量条目，但目录项过多时ls等操作依然缓慢）。
四、结合业务场景的综合建议
不同负载的调优重点不同。数据库场景（如MySQL的InnoDB数据目录）属于大文件顺序写为主，重点是mkfs阶段的条带对齐、独立日志设备以及noatime；日志采集和消息存储场景是典型的追加写密集，除了上述参数，还应关注预读设置和定期清理策略；海量小文件场景（如图片缓存、代码仓库）则更依赖agcount、inode64和页缓存调优，必要时可以考虑关闭不必要的元数据操作。
任何调优都要以数据为依据。建议使用fio在调优前后做基准测试，固定测试模型（如4k随机写、1M顺序写）对比结果，避免凭感觉判断。同时用iostat -x 1观察%util和await，用xfs_info和xfs_db确认配置生效情况。记住调优的基本顺序：先保证数据安全（不随意nobarrier），再做挂载参数这类低风险优化，最后才考虑重新格式化这类高成本操作，每一步都留有回退手段，这样才能在不影响业务的前提下稳步提升XFS的性能表现。