Linux 怎样读取 XFS 文件系统特征

读取已有 XFS 的几何信息与特征标记，最直接的入口是 xfs_info 挂载点。我会先核对挂载对象确实为 XFS，再看输出中的 meta-data、data、naming、log 和 realtime 分组，而不是看到一个特征值就直接下性能或健康结论。

本文只给出只读查询方法，没有在本机执行示例，也不涉及格式化、扩容或修复。xfsprogs 上游手册的在线页面：https://man7.org/linux/man-pages/man8/xfs_info.8.html。工具源项目地址：https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git。

我会先确认查询的是哪个挂载点

如果接手一个“请查 /srv/archive 的文件系统特征”的任务，我会先确认这个路径属于哪个挂载对象。目录存在不等于它本身就是独立挂载点，卷的设备名称也不能凭经验猜测。

# 示例路径必须替换为目标机器真实存在的目录。
findmnt --target /srv/archive --output TARGET,SOURCE,FSTYPE
# 只显示工具版本，不读取或改变文件系统。
xfs_info -V

findmnt 的 FSTYPE 应与目标相符。若不是 xfs，便不应继续把 xfs_info 套到该对象上。SOURCE 可能是逻辑卷或其他映射设备，不一定是一个裸分区。我倾向于先用已确认的挂载点查询，减少手写设备名带来的混淆。

最小查询只需要xfs_info和目标路径

# /srv/archive 在这里代表已经确认的 XFS 挂载点。
xfs_info /srv/archive

xfs_info 展示的是现有文件系统信息，按上游手册说明不会扰动其中的现有内容。手册还支持以包含原始 XFS 的块设备或文件镜像作为参数；日常已挂载环境中，我会优先从挂载点进入，而不为获取信息额外卸载文件系统。

遇到 command not found，先确认目标系统是否有 xfsprogs 以及 PATH 是否包含命令位置；遇到权限错误，按已授权管理流程使用适当权限重试。若对象错误或工具不能识别，先保留错误文字，回查路径与本地手册，不能把查询失败当成文件系统损坏的证明。

把几何信息按区域读开

我更愿意按分组读输出，而不是逐个背缩写。下面的表是阅读索引，不是本机实测日志；字段出现与否、排列和附加标记会随版本与已有格式变化。

isize 指 inode 大小，agcount 是分配组数量，agsize 是分配组大小，需留意输出单位。XFS 的 data 区域不仅含普通文件数据，也包含元数据；内部日志也位于数据区域内。log 是文件系统的元数据日志概念，不应拿它与 /var/log 中的文本日志混用。

对于未配置 realtime 区域的文件系统，看到 none 并不稀奇。它描述一种文件系统布局，不是在告诉你当前没有实时数据流。我觉得这个词最容易让刚接触 XFS 的读者产生误会，因此交接记录里会保留原分组名而不随意翻译成监控术语。

特征位不能替代健康与性能判断

crc=1 表示相应元数据校验特征处于启用状态，不表示用户文件内容都经过端到端校验，更不表示整个文件系统已经完成健康扫描。内核的自描述元数据文档解释了元数据完整性信息的用途：https://docs.kernel.org/filesystems/xfs/xfs-self-describing-metadata.html。

reflink=1 表达文件系统具备相关共享数据区段与写时复制能力，不能据此判断某两个具体文件当前是否共享块，也不能证明某次复制操作用了 reflink。ftype=1 则表示目录结构记录文件类型信息，不是“支持所有文件类型”的业务开关。字段定义可结合上游格式手册阅读：https://man7.org/linux/man-pages/man8/mkfs.xfs.8.html；这里只将其当文档，不执行创建文件系统命令。

我不会为了让输出“看起来更新”就建议修改磁盘格式。读取阶段最有价值的是描述已有状态；是否需要某特征，应由实际应用要求、内核和工具支持范围共同决定。仅有更多的 1，并不等于更好的性能。

我会保留哪些信息作为交接记录

交接时我会保留查询路径、TARGET/SOURCE/FSTYPE、工具版本及完整 xfs_info 输出。这比只截取 reflink=1 更容易让接手者复核对象是否相同。下面是一个紧凑的只读组合，供读者在自己的目标机器上执行：

# 先明确查询对象；以下命令不创建、不修复、不扩容文件系统。
findmnt --target /srv/archive --output TARGET,SOURCE,FSTYPE
# 记录解释输出时所用的工具版本。
xfs_info -V
# 保留完整分组与单位，避免只截取单个特征值。
xfs_info /srv/archive

换算时，要先确认字段所在分组。假设 data 的 bsize 为 4096 字节、blocks 为 262144，这是便于计算的假设值，不是运行输出：两者乘积为 1073741824 字节，即 1 GiB 的 data 区域几何规模，而不是 1 GiB 可用空间。日志或目录分组的 bsize 不应直接混入这个公式。

条带字段也要看单位；xfs_info 输出中的 data sunit、swidth 若标为 blks，应按数据块大小解释，不能不加区分地套用其他命令参数的单位。若是写自动采集工具，我会保留原始输出并处理版本差异，不把所有行固定成永远不变的列数。

哪些情况不该继续套用命令

我要查剩余空间，也只用xfs_info吗？

不适合。它的主用途是几何与特征信息，不是剩余空间报表。应将空间统计与本文的格式信息分开采集，不能用 data blocks 代替可用块数量。

输出没有某个字段，是不是特征一定关闭？

不能直接这样判断。先核对工具版本、本地 man xfs_info 与对应 XFS 格式文档；字段缺失和明确显示为 0 是两件事。不要从另一台机器复制一份“标准输出”作为必然模板。

能否根据这些信息判定文件系统没有损坏？

不能。成功查询只表示获得了相应信息，并没有替代完整健康诊断。若伴随 I/O 错误或内核报错，应按故障处理流程进一步分析，而不是为了查询特征盲目执行修复工具。

对我来说，xfs_info 适合回答“这个已有 XFS 的布局与能力是什么”，不适合回答“它一定健康吗、一定快吗”。确认对象、保留单位、按分组解释，便能把一次只读查询写成有用的存储说明。