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
next prev parent 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).