>>> On Wed, 2 Apr 2008 23:13:15 +0200, Keld Jørn Simonsen >>> <keld@xxxxxxxx> said: [ ... slow RAID reading ... ] >> That could be the usual issue with apparent pauses in the >> stream of IO requests to the array component devices, with >> the usual workaround of trying 'blockdev --setra 65536 >> /dev/mdN' and see if sequential reads improve. keld> Yes, that did it! But that's as usual very wrong. Such a large readhead has negative consequences, and most likely is the result of both some terrible misdesign in the Linux block IO subsystem (from some further experiments it is most likely related to "plugging") and integration of MD into it. However I have found that on relatively fast machines (I think) much lower values of read-ahead still give reasonable speed, with some values being much better than others. For example with another RAID10 I get pretty decent speed with a read-ahead of 128 on '/dev/md0' (but much worse with say 64 or 256). On others 1000 sectors read-ahead is good. The read-ahead needed also depends a bit on the file system type, don't trust tests done on the block device itself. So please experiment a bit to try and reduce it, at least until I find the time to figure out the (surely embarrasing) reason why it is needed and how to avoid it, or the Linux block IO and MD maintainers confess (they almost surely already know why) and/or fix it already. -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
