All of lore.kernel.org
 help / color / mirror / Atom feed
* Question about commit 02e7c5b75cd4ad5176441add156389c71dab6e3a - avoid including wayward devices
@ 2012-05-22 12:59 Alexander Lyakas
  2012-05-24  5:04 ` NeilBrown
  0 siblings, 1 reply; 2+ messages in thread
From: Alexander Lyakas @ 2012-05-22 12:59 UTC (permalink / raw)
  To: NeilBrown, linux-raid

Hi Neil,
can you pls give some details on that commit.

As far as I understand, this change attempts to protect from
split-brain, most typical to RAID1 (but also, e.g., to 4-drive RAID6)
, where part of a mirrored set was assembled independently. The code
first selects "most_recent" based on event count (as usual). Then it
applies the map check to all those devices that are not "most_recent",
and might kick them out, if it detects split-brain.
However, when there is such split-brain, and parts of mirrored sets
are assembled independently, the highest event count does not really
tell us which part of the mirrored set is "more up-to-date". This is
because event count is not tied to any hard clock or something like
that. So there is really no way to tell what part of the mirrored set
will be picked up here (WRT to user activity on the separate mirrored
sets).

What I am trying to say, I guess: don't you think that in such case,
it would be better to warn the user and abort, and not pick (more or
less) arbitrary part of the set? Or, in other words:) might you
reconsider looking at some ideas for split-brain protection I pitched
some time ago?:))

Thanks!
Alex.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Question about commit 02e7c5b75cd4ad5176441add156389c71dab6e3a - avoid including wayward devices
  2012-05-22 12:59 Question about commit 02e7c5b75cd4ad5176441add156389c71dab6e3a - avoid including wayward devices Alexander Lyakas
@ 2012-05-24  5:04 ` NeilBrown
  0 siblings, 0 replies; 2+ messages in thread
From: NeilBrown @ 2012-05-24  5:04 UTC (permalink / raw)
  To: Alexander Lyakas; +Cc: linux-raid

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

On Tue, 22 May 2012 15:59:50 +0300 Alexander Lyakas <alex.bolshoy@gmail.com>
wrote:

> Hi Neil,
> can you pls give some details on that commit.
> 
> As far as I understand, this change attempts to protect from
> split-brain, most typical to RAID1 (but also, e.g., to 4-drive RAID6)
> , where part of a mirrored set was assembled independently. The code
> first selects "most_recent" based on event count (as usual). Then it
> applies the map check to all those devices that are not "most_recent",
> and might kick them out, if it detects split-brain.
> However, when there is such split-brain, and parts of mirrored sets
> are assembled independently, the highest event count does not really
> tell us which part of the mirrored set is "more up-to-date". This is
> because event count is not tied to any hard clock or something like
> that. So there is really no way to tell what part of the mirrored set
> will be picked up here (WRT to user activity on the separate mirrored
> sets).

In a split brain situation *neither* side is "more up-to-date".  They are
both simply "differently up-to-date".  A wall-clock based event count would
not change this fact.

> 
> What I am trying to say, I guess: don't you think that in such case,
> it would be better to warn the user and abort, and not pick (more or
> less) arbitrary part of the set? Or, in other words:) might you
> reconsider looking at some ideas for split-brain protection I pitched
> some time ago?:))

This is a policy question and so I am happy for an extension to the new
"policy" mechanism in mdadm to allow finer control for managing it.
I'm fairy sure that I think the default should be the current behaviour.
If you are assembling the arrays with "-I" it not really possible to reject
the first half of the brain that is found, so I don't think we should when
assembling with "-A".

I'm afraid I don't particularly remember the ideas you pitched before.  Feel
free to pitch them again -- and repeat every few weeks until you get an
answer :-)

NeilBrown

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2012-05-24  5:04 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-05-22 12:59 Question about commit 02e7c5b75cd4ad5176441add156389c71dab6e3a - avoid including wayward devices Alexander Lyakas
2012-05-24  5:04 ` NeilBrown

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.