我有一个 9TB XFS 分区，由 RAID-5 阵列中的四个 3TB 磁盘组成，块大小为 256KB，使用 MDADM。
当我创建分区时，最佳条带单元和宽度值（64 和 192 块）被自动检测并设置，xfs_info 确认了这一点：
# xfs_info /dev/md3
meta-data=/dev/md3 isize=256 agcount=32, agsize=68675072 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=2197600704, imaxpct=5
= sunit=64 swidth=192 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=521728, version=2
= sectsz=512 sunit=64 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
然而，我遇到了传输速度很慢的问题，在调查时我注意到，除非我专门用 安装分区-o sunit=64,swidth=192，否则条带单元始终设置为 512，宽度始终设置为 1536。例如：
# umount /dev/md3
# mount -t xfs -o rw,inode64 /dev/md3 /data
# grep xfs /proc/mounts
/dev/md3 /data xfs rw,relatime,attr2,delaylog,inode64,logbsize=256k,sunit=512,swidth=1536,noquota 0 0
这是预期的行为吗？我想我sunit=64,swidth=192每次都可以用 开始安装它，但这不会使当前数据（在使用 安装时写入的数据sunit=512,swidth=1536）错位吗？
操作系统是 Debian Wheezy，内核为 3.2.51。所有四个硬盘都是高级格式磁盘（smartctl 显示512 bytes logical, 4096 bytes physical）。这些值乘以 8 的事实让我怀疑这是否与问题有关，因为它与 512 和 4096 扇区大小磁盘之间的乘积因子相匹配。
有人可以解释一下这个问题吗？:-)
答案1
您之所以会神秘地乘以 8，是因为 xfs_info 显示 sunit/swidth 是以 bsize 块为单位的，通常为 4096 字节。在 mount 中使用 -o 或 fstab 指定 sunit/swidth 时，它们以 512 字节为单位指定。请注意 xfs_info 示例输出中 sunit/swidth 数字后面的“blks”字符串。4096/512=8，因此是神秘的乘数。
man 5 xfs 在 sunit 节中详细说明了这一点，mkfs.xfs 也是如此，涉及 512B 单位。
man xfs_growfs 兼作 xfs_info 的手册页，详细说明了 xfs_info 的单位是 bsize 字节。
确实很令人困惑。从 UI 角度来看，这是一个非常糟糕的设计选择。
指定“-o sunit=64,swidth=192”可能不是一个好主意，因为您实际上想要的是 64/8=8 和 192/8=24。您可能已经将 8 倍大的值“硬编码”到 FS 中，现在已使用较大的数字挂载它们。手册页非常明确地说明了永远无法切换到较低的 sunit。但是，您可以尝试一下，看看是否会遇到挂载错误。XFS 的挂载应该（但不保证）足够强大，不会吞噬您的数据：它应该只是吐出错误并拒绝挂载，或者使用合理的选项挂载而忽略您指定的选项。先进行备份。
话虽如此，8 倍更大的 sunit/swidth 可能实际上没有什么问题，因为这完全与对齐有关，并且这些数字仍然是对齐的。也许可能存在碎片问题，或者如果您的大多数文件都很小，则会出现问题？
附言：我现在正在研究并发现有趣的是，当您通过添加 1 个磁盘来扩展/重塑 md RAID 时，应该将 sunit/swidth 值更改为什么。从手册页看来，除非您真的将磁盘数量翻倍，否则您无法更改 sunit，但似乎仍然可以更改 swidth。这是否在大多数情况下导致正确对齐还有待观察。实际这样做的人提供的信息似乎很少。