Re: Is Read speed faster when 1 disk is failed on raid5 ?

["Yiqiang Ding" <yqding@rasilient.com>]

Hi Jakob,

Thanks for your kind explanation. Sounds pretty reasonable. I also have done
some tests on raid5 with 4k and 128k chunk size. The results are as follows:
Access Spec     4K(MBps)        4K-deg(MBps)    128K(MBps)
128K-deg(MBps)
2K Seq Read     23.015089       33.293993       25.415035       32.669278
2K Seq Write    27.363041       30.555328       14.185889       16.087862
64K Seq Read    22.952559       44.414774       26.02711        44.036993
64K Seq Write   25.171833       32.67759        13.97861        15.618126

Some conclusions:
1. "Degraded" raid5 has better (sequential) read/write performances. The
biggest difference is in 64k sequential read, almost doubled.
2. Bigger chunk size makes less difference between non-degraded and degraded
RAID5. This is due to less seek penalty for bigger chunksize raid5 according
to Jakob's theory.
3. Bigger chunk size makes worse write performance. Why? Maybe somebody can
explain this.

YQ

----- Original Message -----
From: "Jakob Oestergaard" <jakob@unthought.net>
To: "Yiqiang Ding" <yqding@rasilient.com>
Cc: <raid@ddx.a2000.nu>; <linux-raid@vger.kernel.org>
Sent: Monday, October 28, 2002 4:30 PM
Subject: Re: Is Read speed faster when 1 disk is failed on raid5 ?


> On Mon, Oct 28, 2002 at 01:37:34PM -0800, Yiqiang Ding wrote:
> > Hi Jakob,
> >
> > I don't follow your guesses. Why do you think it may be related to chunk
> > size? Anyway, I'm using 32K.
>
> Because in RAID-5, each disk will hold blocks like:
>
> Disk 0:  [parity] [data]   [data]   [parity]
> Disk 1:  [data]   [parity] [data]   [data]
> Disk 2:  [data]   [data]   [parity] [data]
>
> So when reading blocks 0, 1, 2, 3, 4, ... from the array, we will do:
>
> Read disk 1 block 0
> Read disk 2 block 0
> Read disk 0 block 1
> Read disk 2 block 1
> Read disk 0 block 2
> Read disk 1 block 2
> Read disk 1 block 3
> Read disk 2 block 3
>
> We can do read-ahead, but the access pattern for disk 0 is:
>
> Block 1, block 2, block 4, ...
>
> For disk 1:
>
> Block 0, block 2, block 3, ...
>
> etc...
>
> So we introduce seeks, because of the parity blocks.
>
> Seeking ruins performance.
>
> In a degraded array, the kernel cannot skip the parity blocks, it must
> use them for calculating the lost data.
>
> So my guess is, that this "penalty" actually turns out to be an
> optimization (if the chunk size is small - eg. the number of seeks
> introduced is large). We will do strictly sequential reads on all disks.
>
> So tell me, have I been smoking something, or does this make sense?  :)
>
> Even better - measure degraded vs. non-degraded read performance on a
> RAID-5 array, first with chunk-size 4k, then 32k, then 128k, and post
> the results here   ;)
>
> --
> ................................................................
> :   jakob@unthought.net   : And I see the elder races,         :
> :.........................: putrid forms of man                :
> :   Jakob Østergaard      : See him rise and claim the earth,  :
> :        OZ9ABN           : his downfall is at hand.           :
> :.........................:............{Konkhra}...............:
> -
> 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
>
>


-
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