Re: [Gluster-devel] Proposal for GlusterD-2.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Isn't some of this covered by crm/corosync/pacemaker/heartbeat?

Sorta, kinda, mostly no.  Those implement virtual synchrony, which is
closely related to consensus but not quite the same even in a formal CS
sense.  In practice, using them is *very* different.  Two jobs ago, I
inherited a design based on the idea that if everyone starts at the same
state and handles the same messages in the same order (in that case they
were using Spread) then they'd all stay consistent.  Sounds great in
theory, right?  Unfortunately, in practice it meant that returning a
node which had missed messages to a consistent state was our problem,
and it was an unreasonably complex one.  Debugging
failure-during-recovery problems in that code was some of the least fun
I ever had at that job.  A consensus protocol, with its focus on
consistency of data rather than consistency of communication, seems like
a better fit for what we're trying to achieve.
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-users




[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux