Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Sun, Jan 17, 2016 at 02:09:06AM -0300, Pato Sáinz wrote: > Good evening, > > I've recently started a thread[1] at the Xen-devel list regarding DRBD > and the Protocol D, necessary for Remus, the High Availability/clustering > feature of Xen. The thread outlines in a nutshell the following problems > relevant to DRBD: > > I. Remus depends on a patched version of DRBD[2]. That patch is only > available for DRBD 8.3.9 and 8.3.11. > > II. This means that in order to use Remus, you must use versions > 3.0 through 3.4 of the Linux kernel. Currently there's no distro that > support these versions and even kernel.org sets its end of support > for 3.4 in September of the present year. > > Now, researching this "Protocol D" I've found an old thread[3] in this very > list, requesting the implementation of this feature into the tree: > > Lars pointed out that there may be some issues with that patch and he > explained how he didn't think it was a priority in the near-term back then. > > He encouraged readers to "try and convince him" that Proto D should be > implemented, but nobody replied. 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. > It's a shame that Remus is stuck in such old kernels (even though it's > still a pretty well maintained feature in the Xen tree) and that still, if > someone was to use it and downgrade significantly their kernel, > you'd have to use a version of DRBD that even LINBIT has dropped > paid support for it. > > I think Protocol D should be implemented because: > > I. Remus is actually "the coolest thing that happened to the combination > of virtualization + HA, ever". And there aren't many other alternatives > for this (Remus is supported by Xen in their main tree, too). > > II. The original Protocol D patch was relatively small and shouldn't take > too many man-hours to implement (and I can offer my help to test its > reimplementation, so did Eugene Istomin back in 2013). > > III. In case any developers don't feel sure about Protocol D's consistency, > it still could be enabled via a special Makefile target, #ifdef, or maybe > implemented in a branch outside git master. It would even make a nice > 9.0 feature. > > Anyway, I want to thank everybody at LINBIT for making such a nice > piece of software, I use it on production and it works really well. > > [1]: http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg01820.html > [2]: https://github.com/rshriram/remus-drbd > [3]: http://lists.linbit.com/pipermail/drbd-user/2013-October/020370.html > > -- > Pato Sáinz - @superpatosainz -- : Lars Ellenberg : http://www.LINBIT.com | Your Way to High Availability : DRBD, Linux-HA and Pacemaker support and consulting DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. __ please don't Cc me, but send to list -- I'm subscribed