From: hpa@zytor.com (H. Peter Anvin)
To: linux-raid@vger.kernel.org
Subject: Re: Raidreconf and raid-6
Date: Tue, 30 Mar 2004 22:24:25 +0000 (UTC) [thread overview]
Message-ID: <c4cs2p$p29$1@terminus.zytor.com> (raw)
In-Reply-To: 40603AE7.4050301@wasp.net.au
Followup to: <40603AE7.4050301@wasp.net.au>
By author: Brad Campbell <brad@wasp.net.au>
In newsgroup: linux.dev.raid
>
> G'day all,
>
> I'm in the middle of adding journaling to raidreconf to try and make it resilient to any failures
> except hard disk failures (Power fails, reboots and that kind of thing). It's not pretty, and it
> slows the process down something chronic but hopefully it will make the process bulletproof.
>
> While I'm here I'm looking at trying to add raid-6 support also. I have had a pretty good trawl
> through the raid-6 kernel code and given raidreconf does not do anything with parity blocks it looks
> pretty similar to raid-5 from that respect.
> Are there any gotchas that anyone can think of I should look out for that may trip me up with the
> difference between raid5 & 6 ?
>
> I figure if you could do an easy conversion between raid-5 and raid-6 it might speed up testing and
> adoption of raid-6.
>
Indeed it would, and I would very much appreciate if you'd take this
on, since I'm personally in the middle of moving and not really having
a whole lot of time.
I presume the way raidreconf works is that it reads all the data off a
stripe in format-1 and than writes all the data back to the stripe in
format-2. Since the disk format is inherently unstable during the
conversion it's pretty much the best you can do.
At that point all you need is to have the layout of the blocks, which
is similar to the way they are layed out in RAID-5, and an algorithm
to compute the Q syndromes. There are two ways to accomplish the
latter: one way is to grab the portable C implementation (raid6int.uc)
from the kernel, and the other one is to use the fact that the
full-blown raid-6 implementation in the kernel can be compiled for
userspace testing as well, which would give you top performance.
Please keep me posted; I may not read this mailing list that often for
the next month or so since my Internet connectivity is kind of limited
at the moment.
-hpa
prev parent reply other threads:[~2004-03-30 22:24 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-23 13:25 Raidreconf and raid-6 Brad Campbell
2004-03-30 22:24 ` H. Peter Anvin [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='c4cs2p$p29$1@terminus.zytor.com' \
--to=hpa@zytor.com \
--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 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).