[evidencepi]

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]

    > etcd does provide linearizability with regard to the 
    > logical clock index.

https://twitter.com/aphyr/status/477210387796865024

    > No, it really doesn't. Reads are not monotonic w.r.t 
    > indexes.

[evidencepi]

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]

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.