All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Taejin Kim <taejin1999@davinci.snu.ac.kr>
Cc: linux-raid@vger.kernel.org
Subject: Re: Questions about initialization process of mdadm
Date: Thu, 6 Dec 2012 07:09:41 +1100	[thread overview]
Message-ID: <20121206070941.5829f791@notabene.brown> (raw)
In-Reply-To: <CAKcGETdgabz4TBXqo=+LRRM=0BLpPCd=MxanjiJnD=pdNgEpLw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2253 bytes --]

On Tue, 4 Dec 2012 12:12:23 +0900 Taejin Kim <taejin1999@davinci.snu.ac.kr>
wrote:

> Dear Neil Brown,
> 
> I'm Taejin Kim, Ph.D student at Seoul National Universtiy in Korea.
> Recently, I got interested in RAID for flash memory and just started
> studying about RAID.
> 
> I have seen that there are considerable number of writes during
> initialization of mdadm, reconstructing array from degraded status.
> When I search for what mdadm does, I was able to find your article about
> the RAID5 initialization of mdadm so I now understand what happens.
> (http://marc.info/?l=linux-raid&m=112044009718483&w=2)
> 
> However, I'm wondering why we need to make sure the parity blocks are all
> correct even for a "new" RAID5 array.

Because when a single block is updated, the raid5 module  might use a
read-modify-write cycle.
i.e.
 - read old data and parity
 - subtract old data from parity, and add new data to parity
 - write new data and parity

If the parity block wasn't correct before, then it won't be correct after.

So we must make sure it is correct  at the start.

> In my point of view, there would be no meaningful data in a "new" drive so
> we can write data and parity block from the beginning without having
> consistent parity block calculated from meaningless data in a "new" drive.
> 
> I could come up with one possible reason for the initialization, which is a
> bad block management.
> Is it correct to recognize bad blocks in each drive during initialization
> by trying to write out parity blocks?
> If not, would you explain the reason for this initialization?
> 
> I'm also wondering if this process is necessary only for mdadm or for other
> RAID tools, too.

I believe most RAID implementations perform an initial sync.

md doesn't current require it for other levels (just RAID5 and RAID4) as they
don't do any read-modify-write. However it is possible that the
implementation for RAID6 might change  one day, so don't assume that
--assume-clean is safe for RAID6 long-term.


NeilBrown

> 
> I would appreciate if you let me know above questions. It would be very
> helpful for my research.
> I'm looking forward to your reply.
> Thank you.
> 
> Sincerely.
> 


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

           reply	other threads:[~2012-12-05 20:09 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <CAKcGETdgabz4TBXqo=+LRRM=0BLpPCd=MxanjiJnD=pdNgEpLw@mail.gmail.com>]

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=20121206070941.5829f791@notabene.brown \
    --to=neilb@suse.de \
    --cc=linux-raid@vger.kernel.org \
    --cc=taejin1999@davinci.snu.ac.kr \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.