我们有一个66TB可用空间的备份服务器，设置如下：
12个6TB RAID10arrays – > 12个PV – > 1个VG – > 1个LV – > xfs
这个文件系统专门用于备份（通过BackupPC）。 它收到很多的I / O，但绝对不是硬件应该有麻烦。 但是，我们经历了许多失败的备份，最近我注意到，即使在挂载上写入一个10行文件也需要20秒以上。 运行iostat显示为什么：
[root@lolno BackupPC]# iostat Linux 2.6.18-194.17.1.el5 (lolno) 06/27/2012 avg-cpu: %user %nice %system %iowait %steal %idle 19.93 0.00 9.53 31.95 0.00 38.59 Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn sda 5.34 115.29 43.07 874600222 326773590 sda1 0.00 0.00 0.00 3586 126 sda2 5.34 115.29 43.07 874594516 326773464 sdb 207.33 3544.02 1594.70 26886233184 12097955904 sdc 11.39 844.42 1033.16 6406058328 7837945704 sdd 11.20 622.92 481.77 4725691832 3654875728 sde 15.84 1812.99 1661.13 13754015304 12601927592 sdf 14.86 1483.24 888.80 11252361120 6742733600 sdg 11.67 1020.94 746.05 7745220408 5659828008 sdh 22.60 1127.12 1424.24 8550776952 10804834600 sdi 12.66 1176.71 1043.97 8926929272 7919898000 sdj 13.50 1140.80 912.27 8654489384 6920787296 sdk 13.14 1314.36 1041.48 9971220872 7901060992 sdl 11.16 674.53 366.49 5117257008 2780306920 sdm 10.82 829.36 604.99 6291851320 4589685592 dm-0 2.82 24.81 9.80 188208594 74373432 dm-1 0.00 0.00 0.00 680 0 dm-2 2.52 50.08 5.81 379928338 44067760 dm-3 8.48 40.40 27.46 306454472 208332272 dm-4 364.33 15591.41 11799.05 118282051176 89511839936 正如你所看到的，不是I / O在磁盘/ PV之间均匀分布，绝大部分集中在一个磁盘上。 这会导致什么？
有关系统的更多信息：
它运行CentOS 5.5，内核为2.6.18-194.17.1.el5
[root@lolno BackupPC]# xfs_info /data meta-data=/dev/mapper/backup_vg1-BackupLV isize=256 agcount=66, agsize=268435455 blks = sectsz=4096 attr=0 data = bsize=4096 blocks=17581608960, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=2 = sectsz=4096 sunit=1 blks, lazy-count=0 realtime =none extsz=4096 blocks=0, rtextents=0 [root@lolno BackupPC]# lvdisplay -v /dev/backup_vg1/BackupLV Using logical volume(s) on command line --- Logical volume --- LV Name /dev/backup_vg1/BackupLV VG Name backup_vg1 LV UUID L8i09U-lVxh-1ETM-mNRQ-j3es-uCSI-M1xz45 LV Write Access read/write LV Status available # open 1 LV Size 65.50 TB Current LE 17169540 Segments 12 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:4
我首先想到的是，这与xfs中缺less条带有关，但根据http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/xfsmain.html#xfscreating
“在lvm或md卷上创build文件系统时，mkfs.xfs会select一个最佳几何体。”
那么这是不是在这里发生，还是有其他事情呢？
从agcount=66你可以看到你有66个分配组（66个潜在的IO线程），但只有12个物理块设备。
XFS会尝试将每个新目录放在不同的AG中，所以如果你在同一个目录下做了很多的IO操作，那么你可能会把单线程IO做到存储在一个块设备上的一个AG。
即使你对不同的AG进行IO操作也是可行的，这66个AG中有几个AG位于同一个块设备上。 66/12 = 5.5，所以最多可以有5个IO线程将5个AG的数据写入一个底层块设备。
从sunit=0 swidth=0你可以看到文件系统根本不知道底层的RAIDarrays。
我认为你的文件系统是不正确的。 mkfs.xfs并不是那么聪明。
阅读XFS文档，了解文件系统的结构以及现有数据如何最终传播到这些结构中。 这是一个令人惊讶的容易理解的文件系统。
在这里你处于一个很好的位置，因为你实际上有数据要看，你没有用应用程序开发人员的一些虚构的规范工作，这些规范会随着时间而改变。
重新使您的文件系统更适合您的数据，块设备和RAID布局。 特别是FAQ中的“如何计算正确的sunit，swidth值以获得最佳性能”这个问题将对您有所帮助，但绝对不是您唯一应该注意的事情：