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 Lars: 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). Thanks. [1]: http://net.pku.edu.cn/vc/team/reference/2.pdf -- Pato Sáinz - @superpatosainz