Linux RAID subsystem development
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox