On Tue, 2007-10-23 at 21:21 +0200, Michal Soltys wrote: > Doug Ledford wrote: > > > > Well, first I was thinking of files in the few hundreds of megabytes > > each to gigabytes each, and when they are streamed, they are streamed at > > a rate much lower than the full speed of the array, but still at a fast > > rate. How parallel the reads are then would tend to be a function of > > chunk size versus streaming rate. > > Ahh, I see now. Thanks for explanation. > > I wonder though, if setting large readahead would help, if you used larger > chunk size. Assuming other options are not possible - i.e. streaming from > larger buffer, while reading to it in a full stripe width at least.
Probably not. All my trial and error in the past with raid5 arrays and various situations that would cause pathological worst case behavior showed that once reads themselves reach 16k in size, and are sequential in nature, then the disk firmware's read ahead kicks in and your performance stays about the same regardless of increasing your OS read ahead. In a nutshell, once you've convinced the disk firmware that you are going to be reading some data sequentially, it does the rest. With a large stripe size (say 256k+), you'll trigger this firmware read ahead fairly early on in reading any given stripe, so you really don't buy much by reading the next stripe before you need it, and in fact can end up wasting a lot of RAM trying to do so, hurting overall performance. > > > > I'm not familiar with the benchmark you are referring to. > > > > I was thinking about > http://www.mail-archive.com/linux-raid@vger.kernel.org/msg08461.html > > with small discussion that happend after that. -- Doug Ledford <[EMAIL PROTECTED]> GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband
signature.asc
Description: This is a digitally signed message part
