Goswin von Brederlow wrote:
As I understand it the problem is the hardware. Reading a chunk of
data from a disk means that the head has to seek to the right track
and the disk has to spin to the right position. After that you can
read a full revolution of the disk worth of data sequentially.
Now consider what happens if you read 4K per disk in stripes. The disk
seeks to the right track, spins to the right position and reads
4k. Then it waits for 4k to rotate below the head, read 4k, waits 4k,
read 4k, waits 4k, .... That way both disks are busy without any gain.
I'm not sure about that. All disks have some sort of read-ahead option.
Usually this read-ahead option is configurable too. What if the
read-ahead was set to 2*chunk size (for RAID1 with 2 disks). The
algorithm for reading in parallel from both disks would then be:
1st disk:
current_pos1= read(chunk_size)
seek(current_pos1 + chunk_size)
2nd disk:
seek(current_pos2+chunk_size)
current_pos2= read(chunk_size)
Of course if drive read-ahead works properly (which should be for small
values) the seek() functions would not really cause the drive to seek.
As for the example you mentioned I'm quite sure that reading 4K from a
drive and then seeking 4K forward and reading again would not result in
any slowdown, since most of today's IDE drives have a default read-ahead
of 128KB.
What you would need to do is read one track from one disk, the next
track from the other and so on. But how should the kernel know where
tracks start and end. That is highly device dependent and differs
between the outside and inside of the platter. The geometry values
reported by the disk is purely fictional so the CHS values are no
help.
OTOH, random I/O or multiple threads are being sped up by raid1. And
people have said on the list that using the raid10 module with only two
disks and (IIRC) in offset or far mode will give better read
performance, albeit it reduces write performance.
I found that near copies behave like raid1, offset copies are slower
in both reading and writing (beats me why) and far copies are slightly
faster than near copies in write and twice as fast in read. All for
sequential read/write. For random writes far copies should be slower
to write.
Hmmm, I think a patch is needed to md.4 in order to explain this right
at the source of the confusion.
thanks,
iustin
MfG
Goswin
Thanks,
Dimitris
-
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
