linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakob Oestergaard <jakob@unthought.net>
To: Yiqiang Ding <yqding@rasilient.com>
Cc: raid@ddx.a2000.nu, linux-raid@vger.kernel.org
Subject: Re: Is Read speed faster when 1 disk is failed on raid5 ?
Date: Tue, 29 Oct 2002 01:30:46 +0100	[thread overview]
Message-ID: <20021029003046.GE15779@unthought.net> (raw)
In-Reply-To: <006501c27eca$3a1f0440$707ba8c0@YQDING>

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

  reply	other threads:[~2002-10-29  0:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <02Oct22.043816edt.62658@gpu.utcc.utoronto.ca>
2002-10-22  9:58 ` Is Read speed faster when 1 disk is failed on raid5 ? raid
2002-10-22 10:45   ` Jakob Oestergaard
2002-10-22 10:49     ` raid
2002-10-22 11:24       ` Jakob Oestergaard
2002-10-28 18:27         ` Yiqiang Ding
2002-10-28 21:02           ` Jakob Oestergaard
2002-10-28 21:37             ` Yiqiang Ding
2002-10-29  0:30               ` Jakob Oestergaard [this message]
2002-10-29 21:05                 ` Yiqiang Ding
2002-10-31 11:56                   ` Jakob Oestergaard
2002-10-10 21:18 3ware 7500-12, bad write speed raid
2002-10-17  8:19 ` Is Read speed faster when 1 disk is failed on raid5 ? raid
2002-10-17 11:52   ` raid

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021029003046.GE15779@unthought.net \
    --to=jakob@unthought.net \
    --cc=linux-raid@vger.kernel.org \
    --cc=raid@ddx.a2000.nu \
    --cc=yqding@rasilient.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).