[nSLUG] raid performance (update)
rory at unixism.org
Sat Jun 24 20:50:09 ADT 2006
Thanks to all that replied here or directly to me.
It looks like we found the problem and it has nothing to do with md,scsi
or megaraid. It's a known bug in 2.6.x libc + reiserfs that causes
reiser to use a 128k read-ahead regardless of the underlying read-ahead
config. The problem exhibits in fseek() specifically and can be avoided
by ditching ansi fseek() in favour of pread() or using nolargeio=1 when
This email thread covers the issue:
For our case we'll start with the mount option and then likely re-write
> I know some folks on this list have experience building heavy lifting
> Linux boxen so here's a quandary:
> Having recently switched to 2.6.15 kernel we are finding that the RAID
> performance completely sucks. Specifically RAID 10, on Dell 2850 with a
> Perc4 controller. This is an LSI based controller and therefore uses
> the megaraid driver. This is initially perplexing given that with the
> new I/O schedulers in 2.6 things should improve. We've tried all the
> schedulers including the no-op one with no appreciable change in crappy
> By crappy performance I mean reads are an order of magnitude slower than
> with 2.4 and writes even slower.
> The part that is really burning our collective noodles is that very
> similar performance problems exist when using software raid with 2.6.
> Reverting back to the 2.4 kernel on the same hardware returns
> performance to previous both with megaraid and software raid.
> I'm not the one working directly on the problem but since I've been
> asked for my opinions I thought it would be worthwhile to check here and
> see if this rings a bell for anyone before I dive deep into kernel
> debugging mode.
> nSLUG mailing list
> nSLUG at nslug.ns.ca
More information about the nSLUG