mhf8o9a

Keep in mind that the Bizur is being used for services internal to the file system. So the use case is more like etcd or ZooKeeper's, for example in one role it is a cluster configuration database (with high availablity, fault tolerance, consistency, etc.)

Thanks for the feedback.

As for #3, unfortunately we don't currently have plans to publish a formal proof (we're building a product). Some of our internal documentation is more formal, but we decided on a more readable presentation for this paper.

Bizur team member here.

For etcd benchmarking we used the 'benchmark' tool from etcd's source (commit d62ce55, ~3.1.0-rc1). AFAIK that tool does use the v3 api.

The paper was completed before etcd 3.1 was released. etcd's docs stated (at that time) that the client is not linearizable. We only tested writes.

As for performance, it's hard to say if our results pair up with the official etcd results (we were not aware of them - were they published at the time?). The hardware & software setup used for benchmarking is different.

Latency does increase with concurrency. Latency decreases with the number of keys, as long as they are less than the concurrency. If the number of keys is more than the concurrency, there is no additional benefit and latency remains flat.