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