4 ms·

etcd does provide linearizability with regard to the logical clock index. What you found is not a bug, but a design decision. Maybe the coreos people just sho

etcd does provide linearizability with regard to the logical clock index. What you found is not a bug, but a design decision. Maybe the coreos people just should not assume that linearizability means the same thing to all people. And they should document it clearly.

sagichmal 12y ago
> etcd does provide linearizability with regard to the > logical clock index. https://twitter.com/aphyr/status/477210387796865024 https://twitter.com/aphyr/status/477210387796865024 > No, it really doesn't. Reads are not monotonic w.r.t > indexes.
- evidencepi 12y ago
  Quote from the wiki: A history is linearizable if: its invocations and responses can be reordered to yield a sequential history that sequential history is correct according to the sequential definition of the object if a response preceded an invocation in the original history, it must still precede it in the sequential reordering. Please forgive my stupidness. But could you tell me which one it violates?
  - mononcqc 12y ago
    It is possible that the transaction log's last entry contains a value that is not yet considered 'committed' at large, as per the paper. This transaction needs to be confirmed later on when an additional transaction comes and supercede it, confirming it was committed by all. It is also possible for a leader to be demoted during a split, where the log of that partial transaction will not be counted as final. The new leader at this point can then force a truncation of a follower's log, or ignore it entirely. The entry you have read from a node that was thought to still be a master without first consulting a majority is therefore possibly a bad write that won't be part of history as far as consensus goes. This is explained later in the original Raft paper, and this is why you need to read from the quorum to be able to guarantee consistency under all circumstances, among other problem cases.

sagichmal 12y ago

> etcd does provide linearizability with regard to the > logical clock index. https://twitter.com/aphyr/status/477210387796865024 https://twitter.com/aphyr/status/477210387796865024 > No, it really doesn't. Reads are not monotonic w.r.t > indexes.

evidencepi 12y ago
Quote from the wiki: A history is linearizable if: its invocations and responses can be reordered to yield a sequential history that sequential history is correct according to the sequential definition of the object if a response preceded an invocation in the original history, it must still precede it in the sequential reordering. Please forgive my stupidness. But could you tell me which one it violates?
- mononcqc 12y ago
  It is possible that the transaction log's last entry contains a value that is not yet considered 'committed' at large, as per the paper. This transaction needs to be confirmed later on when an additional transaction comes and supercede it, confirming it was committed by all. It is also possible for a leader to be demoted during a split, where the log of that partial transaction will not be counted as final. The new leader at this point can then force a truncation of a follower's log, or ignore it entirely. The entry you have read from a node that was thought to still be a master without first consulting a majority is therefore possibly a bad write that won't be part of history as far as consensus goes. This is explained later in the original Raft paper, and this is why you need to read from the quorum to be able to guarantee consistency under all circumstances, among other problem cases.