linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Keld Jørn Simonsen" <keld@dkuug.dk>
To: Neil Brown <neilb@suse.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: resync'ing - what is going on
Date: Sat, 12 Jul 2008 13:50:45 +0200	[thread overview]
Message-ID: <20080712115044.GA30938@rap.rap.dk> (raw)
In-Reply-To: <18552.35616.626230.236249@notabene.brown>

On Sat, Jul 12, 2008 at 08:44:48PM +1000, Neil Brown wrote:
> On Saturday July 12, keld@dkuug.dk wrote:
> > I took the information here and made something for the wiki.
> > Comments welcome.  /keld
> 
> Thanks for doing that.  I'm not motivated to work on the wiki myself,
> but I'm more than happy for anyone to take any secrets I divulge in
> emails and publish them there.
> 
> > 
> > = recovery and resync =
> > 
> > The following is a recollection of what Neil Brown and others have
> > written 
> > on the linux-raid mailing list.
> > 
> > "resync" and "recovery" are handled very differently in raid10.
> > "check" and "repair" are special cases of "resync".
> > 
> > == recovery ==
> > 
> > The purpose of the recovery process is to fill a new disk with the
> > relevant 
> > information from a running array.
> > 
> > The assumption is that all data do the new disk needs to be written.
> > 
> > "recovery" walks addresses from the start to the end of the component
> > drives.
> ...
> > 
> > == resync ==
> ...
> > 
> > "resync" walks the addresses from the start to end of the array.
> 
> It's probably worth noting that this difference between recovery and
> resync in specific to raid10.
> 
> recovery always follows the address space of component drives.
> 
> resync:
>   on raid10, follows the address space of the array
>   on raid4/5/6, follows the address space of component drives.
>   on raid1, the two address spaces are the same.
> 
> Another way to say it is that raid10-resync follows the address space
> of the array, everything else follows the component drives.

OK, I added that info:
For raid10 "resync" walks the addresses from the start to end of the
array. (For all other raid types "resync" follows the component drives).

I also added that for recovery, it is assumed
that the running drives are in sync. Is that true? I wrote it as:

The assumption is that all data on the new disk needs to be written, and
that the other data on the running array is correct.


I also wrote this to indicate the difference between a component drive
walk, and a full array walk:

"recovery" walks addresses from the start to the end of the component
drives. Thus only data for the specific component drive is adressed.

      reply	other threads:[~2008-07-12 11:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-10 16:54 resync'ing - what is going on Keld Jørn Simonsen
2008-07-10 17:45 ` Jon Nelson
2008-07-10 18:03 ` Andre Noll
2008-07-11  4:51 ` Neil Brown
2008-07-11 22:29   ` Keld Jørn Simonsen
2008-07-12 10:44     ` Neil Brown
2008-07-12 11:50       ` Keld Jørn Simonsen [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=20080712115044.GA30938@rap.rap.dk \
    --to=keld@dkuug.dk \
    --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).