linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


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