On Sat, 18 Dec 1999, Steffen Ullrich wrote:
> Hi,
> The problem:
> using raid0 gives me a read/write performance of 20..23MByte/s, using
> raid1 (reading) gives only 9MByte/s (hdparm). Checking with dd to
> read/write a 200MByte file it shows that raid1 reading is only as fast
> as raid1 writing is, which is definitly not the expected value
> (dd if=/dev/zero of=/mnt/raid1/tempfile count=409600 to write
> and dd if=/mnt/raid1/tempfile of=/dev/null count=409600 to read)
>
> I've checked in the mail archive (which I've found only available until
> Aug99) and set the chunk size to 128 as suggested there. As a result
> the performance while rebuilding the mirror in the background came up
> to more than 20MByte/s (e.g. reading big chunks from only one disk), but
> once the reconstruction was done it fell down to 9Mbyte/s again.
>
> To make sure that it utilizes both disks in reading I've checked the
> stats of IRQ 14 and 15 (the both IDE channels, check done with sar from
> the sysstat-2.2 package) and it shows that **both** channels are used
> at about 75 interupts per second and channel (cpu usage system around
> 20%) while reading from the raid1, compared to 160 interrupts per second
> and channel (cpu usage system around 40%) when reading from the raid0.
>
The raid1 in raidtools 19990824 uses rather straightforward
method of distributing reads. It spreads reads to raid1 disks
in round-robin fashion. Exception is that if read is sequential
of nature, drive is not changed.
When you think how raid1 works compared to raid0, there is
a clear distinction. In raid0 data is striped among disks,
in raid1 data is identical in all disks:
So when sequentially reading from raid0 array, none of the
disks actually needs to seek. Sequential read from array
will be sequential read for every disk in raid0 array.
But because in raid1 data in disks is identical, sequential
reads will become non sequential in disk level, if reads are
distributed into array, which will lead to bad performance due
to uncessary seeking of disk heads.
That is why sequential reads are currently forced to use
only 1 disk at a time in raid1 arrays. This is not as bad
as it sounds i think. Due to multiuser/multiprocess nature
of linux, this kind of continuous sequential reading below
filesystem level (where the raid code is), is rare rather
than prevailing. If there are lots of separate processes
doing IO the most dominant thing will be seeking.
This is where raid1 true strength is, minimizing
seek latency.
I have made a patch for 19990824 raidtools which
tries to minimize seek latency by using disk which is
nearest to the requested sector, instead of round-robin
read balancing. This leads to improvement in seek times
and also in sequential reads, if they are done parallel
from distinct regions of disk.
You can find this patch at:
http://www.iki.fi/miku/raid1/raid1-readbalance-patch3.gz
This patch also fixes also a bug in raid1_kmalloc.
The results how this patch affects to read,write and seek
speeds can be found at:
http://www.iki.fi/miku/raid1/tests/
If you want to measure the capabilities of your raid1
array you should use tiotest instead of bonnie. tiotest
does IO concurrently which is good in revealing the true limits of your
io subsystems especially in raid1 case. It can be found from:
http://www.iki.fi/miku/tiotest
> Any ideas?
> Any help appreciated.
>
The above stuff helped one system admin to get 40Mbytes/sec
read throughput out of his raid1 array utilizing 2x IBM 10krpm drives.
Which is good considering that he had 40MBytes/sec capable SCSI host
adapter :)
Please let me know if it does/doesn't work for you.
-- Mika <[EMAIL PROTECTED]>
