From: Pallai Roland <dap@mail.index.hu>
To: linux-raid@vger.kernel.org
Cc: Neil Brown <neilb@cse.unsw.edu.au>
Subject: Re: [PATCH] proactive raid5 disk replacement for 2.6.11, updated
Date: Fri, 19 Aug 2005 16:58:31 +0200 [thread overview]
Message-ID: <1124463511.21362.211.camel@localhost.localdomain> (raw)
In-Reply-To: <1124372804.21362.92.camel@localhost.localdomain>
On Thu, 2005-08-18 at 15:46 +0200, Pallai Roland wrote:
> On Thu, 2005-08-18 at 15:28 +1000, Neil Brown wrote:
> > If we want to mirror a single drive in a raid5 array, I would really
> > like to do that using the raid1 personality.
> > [...]
> the current hack allows too, but using the raid1 personality would be a
> clear solution, I agree. although, I have some doubt.. very simple task
> to mirror a drive (some lines of code in raid5.c in this master-slave
> method), but if we call raid1 into the game, the situation goes more
> difficult:
> - we should transfer the badblock cache at the building of raid1
> - the raid1.c should be hacked to make requests for data if the sync
> has stopped due to read error and the parent is a raid5 array
It's harder than I though first, we must know a lot about the raid5
array (parity algorithm, position of the parity disk in that chunk, etc)
to rebuild an arbitary block of a disk if we have only the full stripe
data by make_request. a very ugly hack if I put it all into the raid1.c,
but if I don't, then a special callback is needed from raid1 to raid5
what asks the rebuilding of n-th chunk of a disk, and I don't know how
could I do it nicely.. maybe should I make a generic ioctl for this?
(what's less ugly, but ugly, too)
in this minute, I can't believe that raid1 should be used for proactive
rebuilding.. it's too complex and no real advantage exclusive of
theory.. Neil, give me a hint please if you've see a good solution
otherwise, I've done with a userspace error handler what's called when
a disk seems like failed (steps over badblock threshold) and that
handles the situation instead of error(). using a userspace error
handler was a good idea, thanks for this. that can make a decision (by
calling mdadm) based on SMART values or whatever:
a., fail the drive and do nothing, the array becomes degraded
b., fail the drive, add a spare, rebuild on the classic way
c., don't fail the drive, add a spare and start proactive rebuilding
d., don't fail the drive, schelude userspace badblock rewriting, raise
the badblock tolerance and everything goes on
e., anything what you want..
I'll release the patch with some new features (eg. userspace badblock
rewriter) after I cleaning up the code a little
--
dap
next prev parent reply other threads:[~2005-08-19 14:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-17 23:52 [PATCH] proactive raid5 disk replacement for 2.6.11, updated Pallai Roland
2005-08-18 1:55 ` Tyler
2005-08-18 5:28 ` Neil Brown
2005-08-18 10:24 ` Lars Marowsky-Bree
2005-08-18 14:13 ` Pallai Roland
2005-08-18 10:56 ` Michael Tokarev
2005-08-18 13:46 ` Pallai Roland
2005-08-19 14:58 ` Pallai Roland [this message]
2005-08-20 15:35 ` Pallai Roland
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=1124463511.21362.211.camel@localhost.localdomain \
--to=dap@mail.index.hu \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@cse.unsw.edu.au \
/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).