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
