From: "Keld Jørn Simonsen" <keld@dkuug.dk>
To: Neil Brown <neilb@suse.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: raid5: two writing algorithms
Date: Fri, 8 Feb 2008 02:10:41 +0100 [thread overview]
Message-ID: <20080208011041.GD12985@rap.rap.dk> (raw)
In-Reply-To: <18347.26939.358283.172299@notabene.brown>
On Fri, Feb 08, 2008 at 07:25:31AM +1100, Neil Brown wrote:
> On Thursday February 7, keld@dkuug.dk wrote:
> > As I understand it, there are 2 valid algoritms for writing in raid5.
> >
> > 1. calculate the parity data by XOR'ing all data of the relevant data
> > chunks.
> >
> > 2. calculate the parity data by kind of XOR-subtracting the old data to
> > be changed, and then XOR-adding the new data. (XOR-subtract and XOR-add
> > is actually the same).
> >
> > There are situations where method 1 is the fastest, and situations where
> > method 2 is the fastest.
> >
> > My idea is then that the raid5 code in the kernel can calculate which
> > method is the faster.
> >
> > method 1 is faster, if all data is already available. I understand that
> > this method is employed in the current kernel. This would eg be the case
> > with sequential writes.
> >
> > Method 2 is faster, if no data is available in core. It would require
> > 2 reads and two writes, which always will be faster than n reads and 1
> > write, possibly except for n=2. method 2 is thus faster normally for
> > random writes.
> >
> > I think that method 2 is not used in the kernel today. Mayby I am wrong,
> > but I did have a look in the kernel code.
>
> It is very odd that you would think something about the behaviour of
> the kernel with actually having looked.
>
> It also seems a little arrogant to have a clever idea and assume that
> no one else has thought of it before.
Oh well, I have to admit that I do not understand the code fully.
I am not a seasoned kernel hacker, as I also indicated in my ad hoc
signature.
> > So I hereby give the idea for inspiration to kernel hackers.
>
> and I hereby invite you to read the code ;-)
I did some reading. Is there somewhere a description of it, especially
the raid code, or are the comments and the code the best documentation?
Do you say that this is already implemented?
I am sorry if you think I am mailing too much on the list.
But I happen to think it is fun.
And I do try to give something back.
> Code reading is a good first step to being a
> >
> > Yoyr kernel hacker wannabe
> ^^^^^^^^^^^^^
>
> NeilBrown
Well, I do have a hack in mind, on the raid10,f2.
I need to investigate some more, and possibly test out
what really happens. But maybe the code already does what I want it to.
You are possibly the one that knows the code best, so maybe you can tell
me if raid10,f2 always does its reading in the first part of the disks?
best regards
keld
next prev parent reply other threads:[~2008-02-08 1:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-07 16:13 raid5: two writing algorithms Keld Jørn Simonsen
2008-02-07 20:25 ` Neil Brown
2008-02-08 1:10 ` Keld Jørn Simonsen [this message]
2008-02-08 1:51 ` Neil Brown
2008-02-08 10:25 ` Keld Jørn Simonsen
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=20080208011041.GD12985@rap.rap.dk \
--to=keld@dkuug.dk \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
/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).