News for hackers. Stuff that matters.
Re:Consistency Without Clocks: FaunaDB's Distributed Transac... by jamesblonde on Friday October 19, 2018 @02:19PM (#18258776)
We built HopsFS on NDB, not CalvinDB, because we needed performance for cross-partition transactions. Some workloads need it. In the filesystem workload, when FS path components are normalized and stored on different partitions, practically all transactions cross partitions. So if you serialize them, then writing a file in /home/jchan will block writing a file in /home/jim. This is what most distributed filesystems already do - have a global write lock on the filesystem metadata. I like having the freedom to build my the concurrency model on top of READ_COMMITTED, as i can squeeze out 16X performance improvemnts by doing so (ref: https://www.usenix.org/conference/fast17/technical-sessions/... )
Re:Consistency Without Clocks: FaunaDB's Distributed Transac... by evanweaver on Friday October 19, 2018 @03:26PM (#18259287)
Sure, if you don't care about serializability, you don't need to pay consensus costs to enforce it, but you will be subject to read and write skew.
Re:Consistency Without Clocks: FaunaDB's Distributed Transac... by notacoward on Saturday October 20, 2018 @11:54PM (#18266659)
> This is what most distributed filesystems already do - have a global write lock on the filesystem metadata

Absolutely untrue. Stop lying about other systems.