From: Jakob Oestergaard <jakob@unthought.net>
To: Neil Brown <neilb@cse.unsw.edu.au>
Cc: "H. Peter Anvin" <hpa@zytor.com>, linux-raid@vger.kernel.org
Subject: Re: RAID-6
Date: Wed, 13 Nov 2002 03:13:43 +0100 [thread overview]
Message-ID: <20021113021343.GC22407@unthought.net> (raw)
In-Reply-To: <15825.22660.685310.237185@notabene.cse.unsw.edu.au>
On Wed, Nov 13, 2002 at 06:37:40AM +1100, Neil Brown wrote:
> On Tuesday November 12, jakob@unthought.net wrote:
> >
> > You might want to consider using huge chunk-sizes when reading, but
> > making sure that writes can be made on "sub-chunks" - so that one could
> > run a RAID-6 with a 128k chunk size, yet have writes performed on 4k
> > chunks. This is important for performance on both read and write, but
> > it is an optimization the current RAID-5 code lacks.
>
> Either I misunderstand your point, or you misunderstand the code.
>
> A 4k write request will cause a 4k write to a data block and a 4k
> write to a parity block, no matter what the chunk size is. (There may
> also be pre-reading, and possibly several 4k writes will share a
> parity block update).
Writes on a 128k chunk array are significantly slower than writes on a
4k chunk array, according to someone else on this list - I wanted to
look into this myself, but now is just a bad time for me (nothing new
on that front).
The benchmark goes:
| 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
So down from 27MB/sec to 14MB/sec running 2k-block sequential writes on
a 128k chunk array versus a 4k chunk array (non-degraded).
In degraded mode, the writes degenerate from 30MB/sec to 16MB/sec as the
chunk-size increases.
Something's fishy.
>
> I see no lacking optimisation, but if you do, I would be keen to hear
> a more detailed explanation.
Well if a 4k write really only causes a 4k write to disk, even with a
128k chunk-size array, then something else is happening...
I didn't do the benchmark, and I didn't get to investigate it further
here, so I can't really say much else productive :)
/ Jakob "linux-raid message multiplexer" Østergaard
--
................................................................
: 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-11-13 2:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-11 18:52 RAID-6 H. Peter Anvin
2002-11-11 21:06 ` RAID-6 Derek Vadala
2002-11-11 22:44 ` RAID-6 Mr. James W. Laferriere
2002-11-11 23:05 ` RAID-6 H. Peter Anvin
2002-11-12 16:22 ` RAID-6 Jakob Oestergaard
2002-11-12 16:30 ` RAID-6 H. Peter Anvin
2002-11-12 19:01 ` RAID-6 H. Peter Anvin
2002-11-12 19:37 ` RAID-6 Neil Brown
2002-11-13 2:13 ` Jakob Oestergaard [this message]
2002-11-13 3:33 ` RAID-6 Neil Brown
2002-11-13 12:29 ` RAID-6 Jakob Oestergaard
2002-11-13 17:33 ` RAID-6 H. Peter Anvin
2002-11-13 18:07 ` RAID-6 Peter L. Ashford
2002-11-13 22:50 ` RAID-6 Neil Brown
2002-11-13 18:42 ` RAID-6 Peter L. Ashford
2002-11-13 22:48 ` RAID-6 Neil Brown
[not found] <Pine.GSO.4.30.0211111138080.15590-100000@multivac.sdsc.edu>
2002-11-11 19:47 ` RAID-6 H. Peter Anvin
-- strict thread matches above, loose matches on Subject: below --
2005-11-13 9:05 Raid-6 Rebuild question Brad Campbell
2005-11-13 10:05 ` Neil Brown
2005-11-16 17:54 ` RAID-6 Bill Davidsen
2005-11-16 20:39 ` RAID-6 Dan Stromberg
2005-12-29 18:29 ` RAID-6 H. Peter Anvin
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=20021113021343.GC22407@unthought.net \
--to=jakob@unthought.net \
--cc=hpa@zytor.com \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@cse.unsw.edu.au \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.