我有3个1 TB硬盘和3个500 GB硬盘。 现在，每个大小分组都在一个RAID 5中，这两个都在LVM卷组（带有条纹LV）中。
我发现这对我的小随机写入使用太慢了。 我已经在RAID级别和LVM条带级别上调整了条带大小，以及条带caching和预读缓冲区大小的增加。 按照惯例，我也禁用了NCQ。
所以我已经完成了Linux软件突袭5.没有专用的控制器，这对我的目的是没有用的。
我正在添加另一个1 TB的驱动器和另一个500 GB的驱动器，所以每个4。
如何configuration八个驱动器来获得最佳的小随机写入性能？ 当然不包括简单的RAID 0，因为这个设置的重点显然也是冗余的。 我曾考虑将4 500 GB磁盘放入2个RAID 0中，然后将其添加到其他4个1 TB HD的RAID 10中，以获得6个磁盘RAID 10，但我不确定这是否是最佳解决scheme。 什么说你？
编辑：硬件升级没有更多的预算。 我真正要问的是，就四个1TB驱动器可以直接使用RAID 10而言，我该怎么处理这四个500GB驱动器，使它们最适合于4x1TB RAID 10而不会成为冗余或性能问题？ 我的另一个想法是将RAID 10全部四个500 GB驱动器连接在一起，然后使用LVM将其添加到4x1TB RAID10中。 有什么更好的，你可以想到的？
另一个编辑：现有的数组格式如下：
1 TB ext4 formatted lvm striped file share. Shared to two Macs via AFP. 1 500 GB lvm logical volume exported via iscsi to a Mac, formatted as HFS+. Used a Time Machine backup. 1 260 GB lvm logical volume exported via iscsi to a Mac, formatted as HFS+. Used as a Time Machine backup. 1 200 GB ext4 formatted lvm partition, used a disk device for a virtualised OS installtion. An lvm snapshot of the 500 GB time machine backup. 有一件事我没有尝试过，用ext4文件系统上的一个文件replaceTime Machine LV（使得iscsi挂载指向文件而不是块设备）。 我有一种感觉会解决我的速度问题，但是这会阻止我能够拍摄这些分区的快照。 所以我不确定这是值得的权衡。
在未来，我打算将iPhoto和iTunes库移到另一个HFS + iscsi mount上的服务器上，testing是如何开始注意到随机写入性能。
如果你好奇，我使用这个URL的Raid Math部分的信息： http : //wiki.centos.org/HowTos/Disk_Optimization找出如何设置ext4分区的一切（因此我看到它的优秀performance），但这似乎并没有为iscsi共享HFS +卷做任何好事。
更多的细节：
output of lvdisplay: --- Logical volume --- LV Name /dev/array/data VG Name array LV UUID 2Lgn1O-q1eA-E1dj-1Nfn-JS2q-lqRR-uEqzom LV Write Access read/write LV Status available # open 1 LV Size 1.00 TiB Current LE 262144 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 2048 Block device 251:0 --- Logical volume --- LV Name /dev/array/etm VG Name array LV UUID KSwnPb-B38S-Lu2h-sRTS-MG3T-miU2-LfCBU2 LV Write Access read/write LV snapshot status source of /dev/array/etm-snapshot [active] LV Status available # open 1 LV Size 500.00 GiB Current LE 128000 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 2048 Block device 251:1 --- Logical volume --- LV Name /dev/array/jtm VG Name array LV UUID wZAK5S-CseH-FtBo-5Fuf-J3le-fVed-WzjpOo LV Write Access read/write LV Status available # open 1 LV Size 260.00 GiB Current LE 66560 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 2048 Block device 251:2 --- Logical volume --- LV Name /dev/array/mappingvm VG Name array LV UUID 69k2D7-XivP-Zf4o-3SVg-QAbD-jP9W-cG8foD LV Write Access read/write LV Status available # open 0 LV Size 200.00 GiB Current LE 51200 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 2048 Block device 251:3 --- Logical volume --- LV Name /dev/array/etm-snapshot VG Name array LV UUID 92x9Eo-yFTY-90ib-M0gA-icFP-5kC6-gd25zW LV Write Access read/write LV snapshot status active destination for /dev/array/etm LV Status available # open 0 LV Size 500.00 GiB Current LE 128000 COW-table size 500.00 GiB COW-table LE 128000 Allocated to snapshot 44.89% Snapshot chunk size 4.00 KiB Segments 1 Allocation inherit Read ahead sectors auto - currently set to 2048 Block device 251:7 output of pvs --align -o pv_name,pe_start,stripe_size,stripes PV 1st PE Stripe #Str /dev/md0 192.00k 0 1 /dev/md0 192.00k 0 1 /dev/md0 192.00k 0 1 /dev/md0 192.00k 0 1 /dev/md0 192.00k 0 0 /dev/md11 512.00k 256.00k 2 /dev/md11 512.00k 256.00k 2 /dev/md11 512.00k 256.00k 2 /dev/md11 512.00k 0 1 /dev/md11 512.00k 0 1 /dev/md11 512.00k 0 0 /dev/md12 512.00k 256.00k 2 /dev/md12 512.00k 256.00k 2 /dev/md12 512.00k 256.00k 2 /dev/md12 512.00k 0 0 output of cat /proc/mdstat md12 : active raid5 sdc1[1] sde1[0] sdh1[2] 976770560 blocks level 5, 256k chunk, algorithm 2 [3/3] [UUU] md11 : active raid5 sdg1[2] sdf1[0] sdd1[1] 1953521152 blocks level 5, 256k chunk, algorithm 2 [3/3] [UUU] output of vgdisplay: --- Volume group --- VG Name array System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 8 VG Access read/write VG Status resizable MAX LV 0 Cur LV 5 Open LV 3 Max PV 0 Cur PV 2 Act PV 2 VG Size 2.73 TiB PE Size 4.00 MiB Total PE 715402 Alloc PE / Size 635904 / 2.43 TiB Free PE / Size 79498 / 310.54 GiB VG UUID PGE6Oz-jh96-B0Qc-zN9e-LKKX-TK6y-6olGJl output of dumpe2fs /dev/array/data | head -n 100 (or so) dumpe2fs 1.41.12 (17-May-2010) Filesystem volume name: <none> Last mounted on: /mnt/array/data Filesystem UUID: b03e8fbb-19e5-479e-a62a-0dca0d1ba567 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 67108864 Block count: 268435456 Reserved block count: 13421772 Free blocks: 113399226 Free inodes: 67046222 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 960 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 RAID stride: 128 RAID stripe width: 128 Flex block group size: 16 Filesystem created: Thu Jul 29 22:51:26 2010 Last mount time: Sun Oct 31 14:26:40 2010 Last write time: Sun Oct 31 14:26:40 2010 Mount count: 1 Maximum mount count: 22 Last checked: Sun Oct 31 14:10:06 2010 Check interval: 15552000 (6 months) Next check after: Fri Apr 29 14:10:06 2011 Lifetime writes: 677 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: 9e6a9db2-c179-495a-bd1a-49dfb57e4020 Journal backup: inode blocks Journal features: journal_incompat_revoke Journal size: 128M Journal length: 32768 Journal sequence: 0x000059af Journal start: 1 output of lvs array --aligned -o seg_all,lv_all Type #Str Stripe Stripe Region Region Chunk Chunk Start Start SSize Seg Tags PE Ranges Devices LV UUID LV Attr Maj Min Rahead KMaj KMin KRahead LSize #Seg Origin OSize Snap% Copy% Move Convert LV Tags Log Modules striped 2 256.00k 256.00k 0 0 0 0 0 0 1.00t /dev/md11:0-131071 /dev/md12:0-131071 /dev/md11(0),/dev/md12(0) 2Lgn1O-q1eA-E1dj-1Nfn-JS2q-lqRR-uEqzom data -wi-ao -1 -1 auto 251 0 1.00m 1.00t 1 0 striped 2 256.00k 256.00k 0 0 0 0 0 0 500.00g /dev/md11:131072-195071 /dev/md12:131072-195071 /dev/md11(131072),/dev/md12(131072) KSwnPb-B38S-Lu2h-sRTS-MG3T-miU2-LfCBU2 etm owi-ao -1 -1 auto 251 1 1.00m 500.00g 1 500.00g snapshot linear 1 0 0 0 0 4.00k 4.00k 0 0 500.00g /dev/md11:279552-407551 /dev/md11(279552) 92x9Eo-yFTY-90ib-M0gA-icFP-5kC6-gd25zW etm-snapshot swi-a- -1 -1 auto 251 7 1.00m 500.00g 1 etm 500.00g 44.89 snapshot striped 2 256.00k 256.00k 0 0 0 0 0 0 260.00g /dev/md11:195072-228351 /dev/md12:195072-228351 /dev/md11(195072),/dev/md12(195072) wZAK5S-CseH-FtBo-5Fuf-J3le-fVed-WzjpOo jtm -wi-ao -1 -1 auto 251 2 1.00m 260.00g 1 0 linear 1 0 0 0 0 0 0 0 0 200.00g /dev/md11:228352-279551 /dev/md11(228352) 69k2D7-XivP-Zf4o-3SVg-QAbD-jP9W-cG8foD mappingvm -wi-a- -1 -1 auto 251 3 1.00m 200.00g 1 0 cat /sys/block/md11/queue/logical_block_size 512 cat /sys/block/md11/queue/physical_block_size 512 cat /sys/block/md11/queue/optimal_io_size 524288 cat /sys/block/md11/queue/minimum_io_size 262144 cat /sys/block/md12/queue/minimum_io_size 262144 cat /sys/block/md12/queue/optimal_io_size 524288 cat /sys/block/md12/queue/logical_block_size 512 cat /sys/block/md12/queue/physical_block_size 512
编辑：所以没有人能告诉我这里是否有什么问题？ 根本没有具体的build议？ 嗯。
不好意思，但是RAID5对于小写操作总是不好，除非控制器有足够的caching。 校验和有很多读写操作。
你最好的床是在硬件控制器上的RAID 10 – 真正的尖叫性能得到像Adaptec一样的东西，使半硬盘驱动器SSD ….这种方式所有读取将进入SSD，这将给你吨性能，虽然写显然不得不分裂。 不确定的Linux软件可以做同样的事情。
其余的依赖于你的使用模式，基本上 – 你没有告诉我们任何事情。
选项A.）你需要空间吗？ 您可以将1TB驱动器“缩短”到500GB，并运行一个8磁盘RAID10arrays（对于2TB的可用空间）。 既然你没有提到我会假设他们都是7200rpm的主轴，所以你每秒钟看〜400个随机写入。
这是你最好的性能select，其他任何需要更好的硬件或raid0。
选项B.）1个1TB驱动器的一个4磁盘RAID10arrays，500GB驱动器的另一个4磁盘arrays，简单的lvm跨越。 这就给你200个随机写一个iops和另外200个随机写入iops。
选项C.）所有驱动器中的第一个500GB的一个8磁盘RAID10arrays，然后是1TB驱动器lvm的“back”500GB的4磁盘RAID10arrays。 当你在VG的8磁盘设置部分时，这将会产生400个随机写入iops峰值。
你没有告诉我们有关应用程序的任何事情，如果它的一个顺序日志写你最好的C.如果它分解成至less两个并行写入线程，我宁愿简单的B（不lvm他们在一起）。
除了configurationRAID和LVM之外，您还尝试使用不同的磁盘I / O电梯吗？ CFQ似乎是现在很多发行版的默认设置，对于某些工作负载来说也没什么问题。 对我来说，它已经让我感到非常痛苦 – 例如一台备份服务器备份了大约20台主机，共计大约3000万个文件和几TB数据，出人意料地慢，I / O花费了大量的时间。
在我切换到截止date调度程序之后，该服务器上的所有操作变得大约是以前的两倍。 好吧，在我的情况下，文件系统是（现在还是…）XFS，过去的XFS + CFQ组合已经有了它的陷阱，但值得尝试。
如果您想要立即更改I / O电梯，请执行以下操作：
echo deadline >/sys/block/yourdisk/queue/scheduler
如果你想永久性的改变，在你的grub.conf文件中joinkernel line，或者你使用的启动加载器参数elevator=deadline 。
您也可以尝试anticipatory和noop调度程序。
对于小写操作来说，Raid 5本质上是不好的，因为在写入磁盘之前，必须首先读取每个驱动器上的每个raid块。 硬件控制器通过具有电池支持的高速caching避免了等待磁盘寻找。 这样的caching将帮助所有的小写，而不仅仅是在Raid 5上，但是在那里特别有用。
可能有一个解决scheme，尽pipe：尝试切换您的文件系统logging数据：
tune2fs -o journal_data /dev/md0
（这显然是ext3）
您可能还想要增加日记的大小。 通过使用其他设备进行日记，可以更快地进行。 通常情况下，如果您的系统具有Raid 1，并且数据量大的Raid 5，则首先保留一个音量; 这样做期刊的速度会快得多，因为它需要一半的寻求。 （有关如何执行此操作的更多信息，请参阅man tune2fs）
重要说明：我没有testing过这个。 它应该可以工作，但也有可能它没有提供理论上可以得到的许多优点。