On Wed, 19 Sep 2007, Dean S. Messing wrote:
Justin Piszcz wrote: : Dean Messing wrote: : > Jusin Piszcz wrote: : > : <snip> : > I discovered your January correspondence to the list about this. Yes, : > the read-ahead length makes a dramtic difference---for sequential data : > reading. However, ... <snip> : > : Then re-benchmark. : > : > Large Read-ahead nearly double the speed of 'hdparm -t'. (So does : > simply using the "--direct" flag. Can you explain this?) Also, in : > your opinion, is it wise to use such large read-aheads for a RAID 5 : > intended for the use to which I plan to put it? : : > Did you try increasing the readahead and benchmarking? You can set it : > back to what it was when you are done. Sorry if my earlier reply was not clear. Yes, I did increase r.a. (to 16384 and 32768) and re-ran hdparm each time. Result: r.a. = 512: hdparm -t --> ~67 MB/s " " " hdparm -t --direct --> ~121 MB/s r.a. = 4096: hdparm -t --> ~106 MB/s r.a. = 8192: hdparm -t --> ~113 MB/s r.a. = 16384: hdparm -t --> ~120 MB/s r.a. = 32768: hdparm -t --> ~121 MB/s As I said: it nearly doubled the speed give by 'hdparm -t' But (as I said) so did using the "--direct" flag, which inhibits "page cache" whatever that is. Also (as I asked) what is the downside? From what I have read, random access reads will take a hit. Is this correct? Thanks very much for your help! Dean
Hmm good question, in all of my benchmarking I made sure the majority of the benchmarks increased in overall speed with bonnie++ I did not notice any degradation myself-- although perhaps I was not benchmarking for that workload.
Justin. - 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
