On 2005-03-19T16:06:29, "Peter T. Breuer" <ptb@xxxxxxxxxxxxxx> 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).
> > > Hmm. I don't believe it can detect it reliably. It is always possible
> > > for both sides to have written different data in the ame places, etc.
> >
> > drbd can detect this reliably by its generation counters;
>
> 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.
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.)
That part is really simple in theory.
> 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.
> 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.
Sincerely,
Lars Marowsky-Brée <lmb@xxxxxxx>
--
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
