On Jul 10, 2009, at 11:23 AM, Heinz Mauelshagen wrote:
Dough, I extended dm-raid45's message interface to support changing the xor algorithm and # of chunks, allowing for changes of the algorithm being used at runtime.
Very useful indeed. I may send you some routines to be tested at some point in the future if you don't mind ;-)
This I used to perform a bunch of mkfs write intensive tests on theIntel Core i7 system as an initial write load test case. The tests havebeen run on 8 disks faked onto one SSD using LVM (~200MB sustained writes throughput):
That's a little slower than I think you need for a good test. I'm not even sure I'm satisfied that my current SATA array is sufficient and I can get at least 500MB/s of write throughput to the disks using a raid0, possibly more if I can get a better eSATA port.
for a in xor_blocks do for c in $(seq 2 6) do echo -e "$a $c\n---------------" dmsetup message r5 0 xor $a $c for i in $(seq 6)do time mkfs -t ext3 /dev/mapper/r5 done done done > xor_blocks.out 2>&1 for a in xor_8 xor_16 xor_32 xor_64 do for c in $(seq 2 8) do echo -e "$a $c\n---------------" dmsetup message r5 0 xor $a $c for i in $(seq 6) do time mkfs -t ext3 /dev/mapper/r5 done done done > xor_8-64.out 2>&1 Mapping table for r5:0 146800640 raid45 core 2 8192 nosync raid5_la 7 64 128 8 -1 10 nosync 1 8 -1 \ /dev/tst/raiddev_1 0 /dev/tst/raiddev_2 0 /dev/tst/raiddev_3 0 /dev/ tst/raiddev_4 0 \ /dev/tst/raiddev_5 0 /dev/tst/raiddev_6 0 /dev/tst/raiddev_7 0 /dev/ tst/raiddev_8 0I attached filtered output files xor_blocks_1.txt and xor_8-64_1.txt, which contain the time information for all the above algorithm/#chunks settings. Real time minima: # egrep '^real' xor_blocks_1.txt|sort|head -1 real 0m14.508s # egrep '^real' xor_8-64_1.txt|sort|head -1 real 0m14.430s System time minima: [root@a4 dm-tests]# egrep '^sys' xor_blocks_1.txt|sort|head -1 sys 0m0.460s # egrep '^sys' xor_8-64_1.txt|sort|head -1 sys 0m0.444s User time is negligible. This mkfs test case indicates better performance for certain dm-raid45 xor() settings vs. xor_blocks(). I can get to dbench etc. after my vacation in week 31.
Thanks. This isn't too far off from what I would expect. I would say that real world loads fall all along a spectrum from "create lots of writes, but do little to no work" to "does lots of work, and only sporadically writes". It's the later end of this spectrum that is most likely to be helped by the cache avoiding routines, while the former is not. So, one of the tests I had in mind was to use something like timing a complete kernel build, or doing a database load/report cycle, or some other things like that. Things that do actual work in the foreground while the raid is kept busy in the background. Of course, testing all the various points along the spectrum is needed, so this test gets us the first.
-- Doug Ledford <dledford@xxxxxxxxxx> GPG KeyID: CFBFF194 http://people.redhat.com/dledford InfiniBand Specific RPMS http://people.redhat.com/dledford/Infiniband
Attachment:
PGP.sig
Description: This is a digitally signed message part
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
