From: ptb@lab.it.uc3m.es (Peter T. Breuer)
To: linux-raid@vger.kernel.org
Subject: Re: [PATCH 1/2] md bitmap bug fixes
Date: Sat, 19 Mar 2005 18:19:44 +0100 [thread overview]
Message-ID: <gi3ug2-oub.ln1@news.it.uc3m.es> (raw)
In-Reply-To: 20050319162443.GR18819@marowsky-bree.de
Lars Marowsky-Bree <lmb@suse.de> wrote:
> On 2005-03-19T16:06:29, "Peter T. Breuer" <ptb@lab.it.uc3m.es> wrote:
>
> I'm cutting out those parts of the discussion which are irrelevant (or
> which I don't consider worth pursuing; maybe you'll find someone else
> to explain with more patience).
Probably :-).
> > It doesn't matter what words are used - it can't. If you split the two
> > systems and carry on writing to both, then both "generation counters"
> > will increment in the same way, but you don't have to write the same
> > data to both!
>
> That flag gets said (as part of the generation counter tuple) on both
> sides when that happens, and if it is set on both sides, they know
> something went wrong.
Fine, but ...
> And then they can consult their bitmaps to figure out the set of blocks
> which diverge. (Granted, it's a superset, but typically it'll be a much
> smaller set than the entire volume.)
It doesn't matter - Let them both have exactly the same bitmaps, but let
different data have been written to each of them in those marked blocks.
There's no way of telling which is "good" or "bad", then! It's just a
difference of opinion - the universe bifurcated (it does it all the time
:) and one disk went into one fork and the other disk into the other
fork, and they happily did things for a while, then they got examined
again (the universes joined).
Hey presto! - two disks with perfectly valid but different histories.
Now let their experiences while apart be the same from the point of view
of the metadata, but different at the data level, and you have two disks
that have no distinguishing characteristics at all that you can see or
measure, but they're different.
> That part is really simple in theory.
Knowing which blocks are/may be different does not help them decide who is
_right_.
Lars, I am trying to move you "upwards" from the detail of the
algorithms to a level at which you can see that there is no algorithm
that can decide reliably which of two diverged traces is the more
"valid" in some sense. Whatever your algorithm is, let it decide in a
given case. Say it says "A" is more valid. It looks at certain
characteristics of A and B's bitmaps and maybe other "generation" marks
to decide. Fine. Now let A have B's present data at the time of
divergence and every time data gets written to A in its diverged univese
let it be written with B's present data. The bitmap and the marks will
be the same as before! Now apply your decision algorithm. It chooses A
again (it has the same data to work on). Unfortunately, that's choosing
something that looks just like B! So B was the "more valid"!
> > I can tell what can and cannot happen without having to experience it -
> > that's the whole point of theory :-(. (well, you did ask).
>
> Your theory is flawed.
:(. Oooh, unfortunately not.
> > Quite probably, but all the writings in the world can't change the
> > semantics of the universe :(. Two systems disconnected from each other
> > cannot reliably be told apart without consulting a third "observer" who
> > has been experiencing their actions throughout. You'd have to have them
> > logging to a third node to figure out which is "right" (and which is
> > "left" :-).
>
> Wrong model. They know that at one point in time they've been in sync,
> and that they have since diverged, and so they can figure out where
> those differences occur.
They can't. That's the point. See above rough hack at a proof.
Peter
next prev parent reply other threads:[~2005-03-19 17:19 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-09 22:18 [PATCH 1/2] md bitmap bug fixes Paul Clements
2005-03-09 22:19 ` [PATCH 2/2] " Paul Clements
2005-03-14 4:43 ` [PATCH 1/2] " Neil Brown
2005-03-14 9:44 ` Lars Marowsky-Bree
2005-03-14 10:22 ` Neil Brown
2005-03-14 11:24 ` Lars Marowsky-Bree
2005-03-14 22:54 ` Neil Brown
2005-03-18 10:33 ` Lars Marowsky-Bree
2005-03-18 12:52 ` Peter T. Breuer
2005-03-18 13:42 ` Lars Marowsky-Bree
2005-03-18 14:50 ` Peter T. Breuer
2005-03-18 17:03 ` Paul Clements
2005-03-18 18:43 ` Peter T. Breuer
2005-03-18 19:01 ` Mario Holbe
2005-03-18 19:33 ` Peter T. Breuer
2005-03-18 20:24 ` Mario Holbe
2005-03-18 21:01 ` Andy Smith
2005-03-19 11:43 ` Peter T. Breuer
2005-03-19 12:58 ` Lars Marowsky-Bree
2005-03-19 13:27 ` Peter T. Breuer
2005-03-19 14:07 ` Lars Marowsky-Bree
2005-03-19 15:06 ` Peter T. Breuer
2005-03-19 15:24 ` Mario Holbe
2005-03-19 15:58 ` Peter T. Breuer
2005-03-19 16:24 ` Lars Marowsky-Bree
2005-03-19 17:19 ` Peter T. Breuer [this message]
2005-03-19 17:36 ` Lars Marowsky-Bree
2005-03-19 17:44 ` Guy
2005-03-19 17:54 ` Lars Marowsky-Bree
2005-03-19 18:05 ` Guy
2005-03-19 20:29 ` berk walker
2005-03-19 18:11 ` Peter T. Breuer
2005-03-18 19:43 ` Paul Clements
2005-03-19 12:10 ` Peter T. Breuer
2005-03-21 16:07 ` Paul Clements
2005-03-21 18:56 ` Luca Berra
2005-03-21 19:58 ` Paul Clements
2005-03-21 20:45 ` Peter T. Breuer
2005-03-21 21:09 ` Gil
2005-03-21 21:19 ` Paul Clements
2005-03-21 22:15 ` Peter T. Breuer
2005-03-22 22:35 ` Peter T. Breuer
2005-03-21 21:32 ` Guy
2005-03-22 9:35 ` Luca Berra
2005-03-22 10:02 ` Peter T. Breuer
2005-03-23 20:31 ` Luca Berra
2005-03-25 18:51 ` Peter T. Breuer
2005-03-25 20:54 ` berk walker
2005-03-25 20:56 ` berk walker
2005-03-18 17:16 ` Luca Berra
2005-03-18 17:57 ` Lars Marowsky-Bree
2005-03-18 21:46 ` Michael Tokarev
2005-03-19 9:05 ` Lars Marowsky-Bree
2005-03-19 12:16 ` Peter T. Breuer
2005-03-19 12:34 ` Michael Tokarev
2005-03-19 12:53 ` Peter T. Breuer
2005-03-19 16:08 ` "Robust Read" (was: [PATCH 1/2] md bitmap bug fixes) Michael Tokarev
2005-03-19 17:03 ` "Robust Read" Peter T. Breuer
2005-03-19 20:20 ` Michael Tokarev
2005-03-19 20:56 ` Peter T. Breuer
2005-03-19 22:05 ` Michael Tokarev
2005-03-19 22:30 ` Peter T. Breuer
2005-03-15 4:24 ` [PATCH 1/2] md bitmap bug fixes Paul Clements
2005-03-17 20:51 ` [PATCH 0/3] md bitmap-based asynchronous writes Paul Clements
2005-03-17 20:53 ` [PATCH 1/3] md bitmap async write enabling Paul Clements
2005-03-17 20:55 ` [PATCH 2/3] md bitmap async writes for raid1 Paul Clements
2005-03-17 20:56 ` [PATCH 3/3] mdadm: bitmap async writes Paul Clements
2005-03-21 4:21 ` [PATCH 0/3] md bitmap-based asynchronous writes Neil Brown
2005-03-21 16:31 ` Paul Clements
2005-03-21 22:09 ` Neil Brown
2005-03-22 8:35 ` Peter T. Breuer
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=gi3ug2-oub.ln1@news.it.uc3m.es \
--to=ptb@lab.it.uc3m.es \
--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 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).