[DRBD-user] Regarding an old 2013 thread about Protocol D

Pato Sáinz superpato.sainz at gmail.com
Wed Jan 20 04:40:34 CET 2016

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

2016-01-19 9:42 GMT-03:00 Lars Ellenberg <lars.ellenberg at linbit.com>:
> I don't need social or political convincing that it would be nice
> to have something like that available and working properly.
> I agree.
> I need technical convincing that it is necessary (why is protocol C not
> good enough?), and that it can actually work, and *why* it would work.
> Not just by accident in calm weather, where no-one can ever detect
> inconsistencies between memory and storage and IO state and other
> checkpoints, because it is not excercised.
> But that it continues to "do the right thing" during storm and failures.
> And no-one tried to do that.
> Not even tried.
> --
> : Lars Ellenberg


I wholly understand your concerns: it wouldn't be wise to ship something
that just breaks within DRBD (which in turn, is shipped with Linux).

The original Remus paper[1] briefly describes the storage model
(checkpointing, etc.) but about the implementation itself (the original patch
by Shriram), I fear I am unable to convince you via the technical way: it is not
my area of expertise (it seems you need a kind of "formal proof" for consistency
and a lack of races: and I don't even do much C to begin with).

I am CC'ing the Remus maintainers and Shriram himself to see if they can
add anything.

Additionally: are you suggesting that Protocol C is a fine replacement for
Protocol D? (I've read the DRBD docs).


[1]: http://net.pku.edu.cn/vc/team/reference/2.pdf

Pato Sáinz - @superpatosainz

More information about the drbd-user mailing list