Re: Lock contention in raid(4)?

[Greg Oster <oster%cs.usask.ca@localhost>]

Matthias Scheler writes:
> 
>       Hello,
> 
> I'm still playing with the two new fast SATA disks. Both disks can
> deliver a linear read performance of more than 100MB/sec. I combined
> them to a RAID 1 with RAIDframe ...
[snip]
> ... and measured read performance again:
> 
> tron@lyssa:/home/tron#dd of=/dev/null if=/dev/rraid0d bs=1m count=2048
> 2048+0 records in
> 2048+0 records out
> 2147483648 bytes transferred in 19.525 secs (109986358 bytes/sec)
> 
> This is somewhat disappointing because a single disk can deliver almost
> the same performance. If I try to read from both disks in parallel
> manually the performance is much better:
> 
> tron@lyssa:~#dd if=/dev/rwd1d of=/dev/null bs=1m count=2048& ;dd if=/dev/rwd2
> d of=/dev/null bs=1m count=2048
> [1] 2710
> 2048+0 records in
> 2048+0 records out
> 2147483648 bytes transferred in 23.855 secs (90022370 bytes/sec)
> [1]  + done       dd if=/dev/rwd1d of=/dev/null bs=1m count=2048
> 2048+0 records in
> 2048+0 records out
> 2147483648 bytes transferred in 24.071 secs (89214558 bytes/sec)
> 
> Is there some locking in the kernel which gets in the way?

No..  RAIDframe's RAID 1, in general, doesn't attempt to read from
both disks at the same time for a single read stream.  The "what disk
do I get this from" algorithms will tend to favor using the disk that
is currently 'closest' to the requested data.  With no other reads 
happening, that will typically always be just one of the disks, as 
that disk's head will be closest to the 'next data'.  If you try doing 
two simultanous reads of different parts of the RAID set you should see 
performance values closer to what you expect -- one read should come 
from one disk, and the other read from the other disk, thus pushing 
both disks at the same time.

Later...

Greg Oster