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 --]
parent 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