Re: RAID1 and load-balancing during read

[Dimitrios Apostolou <jimis@gmx.net>]

Dimitrios Apostolou wrote:
> 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.
> 
On a second thought I realise that this doesn't work as expected... Even 
though this will not cause slowdown, it will not cause speedup either. 
It is obvious that if a drive reads sequentially with 40MB/s, it won't 
surpass that speed no matter what seeks you do. Readahead might help to 
avoid disk head seeks, but read speed just can't increase. I don't know 
what I was thinking when writing this... :-s


Thanks for your replies,
Dimitris