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: Thu, 31 Oct 2002 12:56:08 +0100	[thread overview]
Message-ID: <20021031115608.GE30823@unthought.net> (raw)
In-Reply-To: <008c01c27f8e$fb63a3d0$707ba8c0@YQDING>

On Tue, Oct 29, 2002 at 01:05:59PM -0800, Yiqiang Ding wrote:
> Hi Jakob,
> 

Hello Ding,

> 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

Very interesting !

> 
> 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.

I'm going wild-guessing on (3) here...

It could be, that while you are writing your file, a write smaller than
your chunk size is scheduled by the VM (or something - I'm not exactly a
block/VM interaction wizard) - so a 128k parity block is written out.
Some time later, the rest of the parity block is scheduled for writing,
and the same but recalculated 128k parity block is written out once
again.

Neil, or anyone else with more kernel understanding than me, please
comment on that   :)

A work-around for this, as I see it, would be to change the RAID-5
driver so that it - during *writing* only - internally works on 512 byte
"sub-chunks" *no*matter* the actual chunk size on the array.

This does not break compatibility with existing RAIDs as I see it - no
additional information is needed in the superblock either. I think this
optimization could be done completely transparently.

I'd love to come up with a patch, but there's a zero likelihood of that
happening before the weekend.

-- 
................................................................
:   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-31 11:56 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
2002-10-29 21:05                 ` Yiqiang Ding
2002-10-31 11:56                   ` Jakob Oestergaard [this message]
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=20021031115608.GE30823@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).