[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140107100750.GA16044@gmail.com>
Date: Tue, 7 Jan 2014 11:07:50 +0100
From: Andrea Mazzoleni <amadvance@...il.com>
To: NeilBrown <neilb@...e.de>
Cc: Andrea Mazzoleni <amadvance@...il.com>,
linux-kernel@...r.kernel.org, linux-raid@...r.kernel.org,
linux-btrfs@...r.kernel.org, clm@...com, jbacik@...com
Subject: Re: [RFC] lib: raid: New RAID library supporting up to six parities
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists