3.10. 从 ext4 迁移到 XFS

Ext3/4 在引导时在用户空间中运行 e2fsck，以根据需要恢复日志。相比之下，XFS 在内核空间中在挂载时执行日志恢复。提供了一个 fsck.xfs shell 脚本，但不会执行任何有用的操作，因为它只能满足 initscript 要求。

当请求 XFS 文件系统修复或检查时，请使用 xfs_repair 命令。对只读检查使用 -n 选项。

xfs_repair 命令不会在带有脏日志的文件系统中运行。若要修复此类文件系统 挂载 和 卸载，必须先执行此类文件系统挂载和卸载，才能重播日志。如果日志损坏且无法重播，则可以使用 -L 选项来零注销日志。

有关 XFS 文件系统修复的详情，请参考 第 12.2.2 节 “XFS”

当遇到元数据错误时，ext3/4 文件系统具有可配置的行为，默认行为只是继续。XFS 遇到无法恢复的元数据错误时，它将关闭文件系统并返回 EFSCORRUPTED 错误。系统日志将包含遇到的错误的详细信息，如有必要，将建议运行 xfs_repair。

XFS 配额不是一个可重新挂载的选项。必须在初始挂载上指定 -o quota 选项才能生效配额。

虽然配额软件包中的标准工具可以执行基本的配额管理任务（如 setquota 和 repquota），但 xfs_quota 工具可用于特定于 XFS 的功能，如项目配额管理。

quotacheck 命令对 XFS 文件系统没有影响。在 XFS 上第一次打开配额记帐时，会在内部自动进行 配额检查。由于 XFS 配额元数据是第一类日志记录元数据对象，因此配额系统始终一致，直到手动关闭配额为止。

XFS 文件系统没有可缩小文件系统的工具。可以通过 xfs_growfs 命令在线增大 XFS 文件系统。

对于大于 1 TB 且索引节点 256 字节或大于 2 TB（带 512 字节索引节点的文件系统），XFS 索引节点编号可能会超过 2^32。这样庞大的索引节点编号会导致 32 位 stat 调用失败，并显示 EOVERFLOW 返回值。当使用默认的 Red Hat Enterprise Linux 7 配置时，可能会出现上述问题：没有带四个分配组。自定义配置（如文件系统扩展或更改 XFS 文件系统参数）可能会导致行为不同。

应用程序通常正确处理这样的大型索引节点编号。如果需要，使用 -o inode32 参数挂载 XFS 文件系统，以强制 2^32 以下索引节点编号。请注意，使用 索引节点32 不会影响已分配了 64 位编号的索引节点。

XFS 使用 规范预分配 来在写入文件时分配过去 EOF 的块。这可避免 NFS 服务器上的并发流写入工作负载导致文件碎片。默认情况下，这个预分配会增加文件的大小，并会在"du"输出中显示。如果具有投射预分配的文件未在五分钟内进行目录，则将丢弃预分配。如果在该时间之前将索引节点循环出缓存，则在恢复索引节点时将丢弃预分配。

如果因为推测预分配而发现了 ENOSPC 问题，则可使用 -o allocsize=amount 挂载选项指定固定的预分配量。

由于启发性和行为（如延迟分配和推测预分配），碎片很少是 XFS 文件系统的大问题。但是，有一些工具可用于测量文件系统碎片以及对文件系统进行碎片整理。不鼓励使用这些服务。

xfs_db frag 命令尝试将所有文件系统分配分解为单个碎片数，以百分比表示。命令的输出需要大量的专业知识才能理解其含义。例如，碎片因数为 75%，表示每个文件的平均扩展率为 4 个扩展。因此，xfs_db 的片段的输出不被视为有用，因此建议更加谨慎地分析任何碎片问题。