Re: Awful RAID5 random read performance

[Bill Davidsen <davidsen@tmr.com>]

Goswin von Brederlow wrote:
> John Robinson <john.robinson@anonymous.org.uk> writes:
>
>   
>> On 03/06/2009 19:38, Bill Davidsen wrote:
>>     
>>> John Robinson wrote:
>>>       
>>>> On 02/06/2009 20:47, Keld Jørn Simonsen wrote:
>>>>         
>> [...]
>>     
>>>>> In your case, using 3 disks, raid5 should give about 210 % of the
>>>>> nominal
>>>>> single disk speed for big file reads, and maybe 180 % for big file
>>>>> writes. raid10,f2 should give about 290 % for big file reads and 140%
>>>>> for big file writes. Random reads should be about the same for raid5 and
>>>>> raid10,f2 - raid10,f2 maybe 15 % faster, while random writes should be
>>>>> mediocre for raid5, and good for raid10,f2.
>>>>>           
>>>> I'd be interested in reading about where you got these figures from
>>>> and/or the rationale behind them; I'd have guessed differently...
>>>>         
>>> For small values of N, 10,f2 generally comes quite close to N*Sr,
>>> where N is # of disks and Sr is single drive read speed. This is
>>> assuming fiarly large reads and adequate stripe buffer
>>> space. Obviously for larger values of N that saturates something
>>> else in the system, like the bus, before N gets too large. I don't
>>> generally see more than (N/2-1)*Sw for write, at least for large
>>> writes. I came up with those numbers based on testing 3-4-5 drive
>>> arrays which do large file transfers. If you want to read more than
>>> large file speed into them, feel free.
>>>       
>
> With far copies reading is like reading raid0 and writing is like
> raid0 but writing twice with a seek between each. So (N/2) and (N/2-a
> bit) are the theoretical maximums and raid10 comes damn close to those.
>
>   
>> Actually it was the RAID-5 figures I'd have guessed differently. I'd
>> expect ~290% (rather than 210%) for big 3-disc RAID-5 reads, and ~140%
>> (rather than "mediocre") for random small writes. But of course I
>> haven't tested.
>>     
>
> That kind of depends on the chunk size I think.
>
> Say you have a raid 5 with chunk size << size of 1 track. Then on each
> disk you read 2 chunks, skip a chunk, read 2 chunks, skip a chunk. But
> skipping a chunk means waiting for the disk to rotate over it. That
> takes as long as reading it. You shouldn't even get 210% speed.
>
> Only if chunk size >> size of 1 track could you seek over a
> chunk. And you have to hope that by the time you have seeked the start
> of the next chunk hasn't rotated past the head yet.
>
> Anyone know what the size of a track is on modern disks? How many
> sectors/track do they have?
>   

It varies to keep the bpi constant, so there are more sectors on outer 
tracks and transfer rate is higher. raid10 can use outer tracks in more 
cases (with the "far" layout) and thus delivers a higher transfer rate. 
Or so the theory goes, in practice raid10 *does* give a higher transfer 
rate, so the above is theory to explain the observed facts.

-- 
Bill Davidsen <davidsen@tmr.com>
  Even purely technical things can appear to be magic, if the documentation is
obscure enough. For example, PulseAudio is configured by dancing naked around a
fire at midnight, shaking a rattle with one hand and a LISP manual with the
other, while reciting the GNU manifesto in hexadecimal. The documentation fails
to note that you must circle the fire counter-clockwise in the southern
hemisphere.



--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html