linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Mazzoleni <amadvance@gmail.com>
To: NeilBrown <neilb@suse.de>
Cc: Andrea Mazzoleni <amadvance@gmail.com>,
	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:07:50 +0100	[thread overview]
Message-ID: <20140107100750.GA16044@gmail.com> (raw)
In-Reply-To: <20140107113357.3bd67ad0@notabene.brown>

Hi Neil,

On 01/07, NeilBrown wrote:
> > To do the same with up to six failures, it's now required some kind of sort
> > function.
> 
> 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.

If the the async_tx and btrfs layers can always provide indexes in order,
for sure this sort function can be removed. I agree with you that it would be
a better design.

In fact, the raid library never uses it directly. It's just provided to help the
callers that for whatever reason cannot provide such indexes in order.
And seeing these swap operations between faila/failb in both btrfs and async_tx,
made me to assume that the order is not always correct.

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

The new raid library, like the existing raid6, requires to have the indexes of
the failed blocks in order. With only two indexes faila/failb this means
faila < failb and sorting is equivalent to find the first one.

But with up to six failures, is like to have six fail variables:
faila/failb/failc/faild/faile/failf and the raid library requires them
to be in order as: faila < failb < failc < faild < faile < failf.
In this general case a sort function is the only one that gives the guarantee
to fulfill this requirement whatever is the original order.

Ciao,
Andrea

      reply	other threads:[~2014-01-07 10:07 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
2014-01-07 10:07       ` Andrea Mazzoleni [this message]

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=20140107100750.GA16044@gmail.com \
    --to=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 \
    --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).