[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-raid
Subject:    Re: raid10 performance question
From:       Bill Davidsen <davidsen () tmr ! com>
Date:       2007-12-26 20:59:37
Message-ID: 4772C0B9.4080809 () tmr ! com
[Download RAW message or body]

Peter Grandi wrote:
>>>> On Tue, 25 Dec 2007 19:08:15 +0000,
>>>> pg_lxra@lxra.for.sabi.co.UK (Peter Grandi) said:
>>>>         
>
> [ ... ]
>
>   
>>> It's the raid10,f2 *read* performance in degraded mode that is
>>> strange - I get almost exactly 50% of the non-degraded mode
>>> read performance. Why is that?
>>>       
>
>   
>> [ ... ] the mirror blocks have to be read from the inner
>> cylinders of the next disk, which are usually a lot slower
>> than the outer ones. [ ... ]
>>     
>
> Just to be complete there is of course the other issue that
> affect sustained writes too, which is extra seeks. If disk B
> fails the situation becomes:
>
>     DISK
>    A X C D
>
>    1 X 3 4
>    . . . .
>    . . . .
>    . . . .
>    -------
>    4 X 2 3       
>    . . . .
>    . . . .
>    . . . .
>
> Not only must block 2 be read from an inner cylinder, but to
> read block 3 there must be a seek to an outer cylinder on the
> same disk. Which is the same well known issue when doing
> sustained writes with RAID10 'f2'.

I have often wondered why the elevator code doesn't do better on this 
sustained load, grouping the writes at the drive extremities so there 
would be lots of writes to nearby cylinders then a big seek and lots of 
writes near the next position. I tried bumping the stripe_cache, 
changing to alternate elevators, and just increasing the physical 
memory, and never saw any serious improvement beyond the speed with 
default settings.

-- 
Bill Davidsen <davidsen@tmr.com>
  "Woe unto the statesman who makes war without a reason that will still
  be valid when the war is over..." Otto von Bismark 


-
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
[prev in list] [next in list] [prev in thread] [next in thread]