From: NeilBrown <neilb@suse.de>
To: Killian De Volder <killian.de.volder@megasoft.be>,
Henry Cai <henryplusplus@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: Two Questions about Linux MD
Date: Sat, 19 Jul 2014 19:21:57 +1000 [thread overview]
Message-ID: <20140719192157.48487e7c@notabene.brown> (raw)
In-Reply-To: <53CA31C4.2020705@megasoft.be>
[-- Attachment #1: Type: text/plain, Size: 2522 bytes --]
On Sat, 19 Jul 2014 10:52:20 +0200 Killian De Volder
<killian.de.volder@megasoft.be> wrote:
>
>
> See answser below:
>
> Ps. You added extra spaces on the bit line ? Why did you do this ?
> You should be using monospace fonts / fixed-with for mailing lists.
>
> Killian De Volder
>
> On 19-07-14 05:15, Henry Cai wrote:
> > 1> The first question, as the wiki:
> > https://raid.wiki.kernel.org/index.php/Initial_Array_Creation
> >
> > There has the sentence, "For raid5 there is an optimisation: mdadm
> > takes one of the disks and marks it as 'spare' ", what I want to know
> > is the optimisation for what? The result of the optimisation is that
> > when initial create, the RAID5 is do recovery not resync.
> >
> > And in the mdadm man
> > page:http://www.linuxmanpages.com/man8/mdadm.8.php, also has an option
> > --force, describe as follow: "Normally mdadm will not allow creation
> > of an array with only one device, and will try to create a raid5 array
> > with one missing drive (as this makes the initial resync work faster).
> > With --force, mdadm will not try to be so clever. "
> Don't know how this is faster, sorry, maybe someone else on the mailing
> list know.
I suspect you can work it out if you try.
Think about the exact sequence of IO requests needed to correct the parity
blocks assuming the are not correct.
Now think of the exact sequence of IO requests needed to recover to a spare.
Remember the seeking is slow on rotating storage.
Remember also that the parity block changes device every chunk.
I'm sure you'll work it out.
> > Last, if bitmap save on all disks, how to keep the bitmap consistent?
> > How to address the situation that the bitmaps are different when read
> > from the disks after system boot?
> If linux-raid has troubles keeping the bitmap consistent,
> I'd be a lot more concerned about your data :)
> Also they probably use some tricks with write barriers, and flushes
> and other data to figure out which ones to use.
>
> That's for someone smarter on the list.
If the different copies of the bitmap contain different contents, then it
must be safe to use any of them.
Think through the different scenarios that could result in an inconsistency
and see if this is true.
Remember that when we bit is set in the bitmap (to say that we intend to
write to the corresponding region), we wait until the new bitmap has been
written to all devices before permitting the write to commence.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2014-07-19 9:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <53CA304E.4040908@megasoft.be>
2014-07-19 8:52 ` Fwd: Re: Two Questions about Linux MD Killian De Volder
2014-07-19 9:21 ` NeilBrown [this message]
2014-07-18 14:21 Henry Cai
2014-07-18 15:30 ` Killian De Volder
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=20140719192157.48487e7c@notabene.brown \
--to=neilb@suse.de \
--cc=henryplusplus@gmail.com \
--cc=killian.de.volder@megasoft.be \
--cc=linux-raid@vger.kernel.org \
/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.