From: NeilBrown <neilb@suse.de>
To: Andrea Mazzoleni <amadvance@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org,
linux-btrfs@vger.kernel.org, clm@fb.com, jbacik@fb.com
Subject: Re: [RFC] lib: raid: New RAID library supporting up to six parities
Date: Tue, 7 Jan 2014 11:33:57 +1100 [thread overview]
Message-ID: <20140107113357.3bd67ad0@notabene.brown> (raw)
In-Reply-To: <20140106094523.GA4602@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]
On Mon, 6 Jan 2014 10:45:23 +0100 Andrea Mazzoleni <amadvance@gmail.com>
wrote:
> Hi Neil,
>
> Thanks for your feedback. In the meantime I went further in developing and
> I've just sent version 2 of the patch, that contains a preliminary btrfs
> modification to use the new interface.
>
> Please use this one for any kind of review because it contains a modification
> of the interface to match better the btrfs use.
> I'll now try to do something similar to the async_tx layer and to improve the
> code documentation as you recommended.
Thanks.
>
> Anyway, a good entry point to understand the code is to start from the
> include/linux/raid/raid.h file. It contains the functions that external
> modules should call with a complete description of them.
>
> There is raid_par() used to compute parity, and raid_rec() to recover damaged
> blocks. These two functions replace all the old xor_blocks and raid6 calls.
>
> And there is the raid_sort() you mention. It's an helper function that can be
> used to ensure that the blocks indexes are passed at the raid interface in
> proper order. In existing code I saw that the indexes are often sorted before
> calling raid6, with something like:
>
> if (faila > failb) {
> int tmp = failb;
> failb = faila;
> faila = tmp;
> }
>
> To do the same with up to six failures, it's now required some kind of sort
> function.
I'm not totally convinced by this, but then I haven't played with the code
so maybe I'm wrong.
I don't see the above as "sorting" faila and failb, but rather determining
which one is first. Once you know which one is first, the remainder follow
in order.
So I would probably just make sure we always process the block is the "right"
order. Then sorting would be irrelevant.
But as I say, I haven't fiddled with the code, so maybe that would end up
being more complex.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2014-01-07 0:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-03 9:47 [RFC] lib: raid: New RAID library supporting up to six parities Andrea Mazzoleni
2014-01-06 0:15 ` NeilBrown
2014-01-06 9:45 ` Andrea Mazzoleni
2014-01-07 0:33 ` NeilBrown [this message]
2014-01-07 10:07 ` Andrea Mazzoleni
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=20140107113357.3bd67ad0@notabene.brown \
--to=neilb@suse.de \
--cc=amadvance@gmail.com \
--cc=clm@fb.com \
--cc=jbacik@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
/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.