From: NeilBrown <neilb@suse.de>
To: Peter Grandi <pg@lxra2.for.sabi.co.UK>
Cc: Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: LVM RAID1 syncing component
Date: Tue, 2 Dec 2014 10:28:11 +1100 [thread overview]
Message-ID: <20141202102811.2e93ff9f@notabene.brown> (raw)
In-Reply-To: <21625.58812.321750.229562@tree.ty.sabi.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]
On Sat, 29 Nov 2014 15:26:52 +0000 pg@lxra2.for.sabi.co.UK (Peter Grandi)
wrote:
> [ ... ]
>
> > During a resync (after an unclean shutdown) the devices are
> > indistinguishable. RAID1 reads all drives and if there is a
> > difference it chooses one data block to write to the others -
> > always the one with the lowest index number.
>
> Uhhhhh "indistinguishable" and "lowest index number"?
>
> Shouldn't that be "lowest index number among those with the
> highest event count"?
>
> Put another way, couldn't it happen that in a 5-way RAID1 for
> example an unclean shutdown results in 2 drives with the same
> highest event count and 3 drives with lower event counts, and
> then the data page to write is that from the one of the 2 with
> the lowest index number and is written only to the 3 with the
> lower event count?
>
> Also, in case of an «unclean shutdown» resulting in all members
> of a RAID1 set having the same event count, is the resync still
> done? Is it necessary? Or is «unclean shutdown» used here as an
> alias for "not all event counts are the same".
>
> I am asking as to what RAID1 actually does mostly, but also
> perhaps as to what it ought to be doing.
I've told you what it actually does. I think that is what it ought to do.
If you think that maybe it ought to do something differently from what it
does, I suggest you try to come up with a specific scenario where what
actually happens is not optimal, and give clear reasons for why you think
something else is optimal.
To be specific, after an unclean shutdown, the array is assembled from all
devices which have an uptodate event count, and then all blocks are compared
and where a difference is found, data is copies from the lowest index number
block to the others.
"uptodate" in the context of event counts means the event count is equal to,
or one less than, the highest event count found.
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
next prev parent reply other threads:[~2014-12-01 23:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-25 4:07 LVM RAID1 syncing component Joe Lawrence
2014-11-26 5:42 ` Chris Murphy
2014-11-26 13:20 ` Joe Lawrence
2014-11-26 20:41 ` NeilBrown
2014-11-29 15:26 ` Peter Grandi
2014-12-01 23:28 ` NeilBrown [this message]
2014-12-01 21:19 ` Joe Lawrence
2014-12-01 21:27 ` Joe Lawrence
2014-12-01 21:41 ` NeilBrown
2014-12-02 19:05 ` Joe Lawrence
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=20141202102811.2e93ff9f@notabene.brown \
--to=neilb@suse.de \
--cc=linux-raid@vger.kernel.org \
--cc=pg@lxra2.for.sabi.co.UK \
/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).