Torus: A distributed storage system by CoreOS
Okay, so from reading the developer docs at <a href="https:&#x2F;&#x2F;github.com&#x2F;coreos&#x2F;torus&#x2F;Documentation" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;coreos&#x2F;torus&#x2F;Documentation</a>, I&#x27;m inferring that:<p>* Single reader&#x2F;writer. If you try and set up more, Bad Things happen (even if it&#x27;s single-writer, you don&#x27;t get read-after-write consistency).<p>* It sure sounds like network partitions will allow all kinds of badness.<p>* If copy 1 goes down, you can keep operating on copy 2, then lose copy 2, have copy 1 come back up, and then warp back in time? Maybe that&#x27;s prevented because of append-only and you just lose the data entirely because it was only replicating to one node due to the &quot;temporary&quot; failure.<p>Most egregiously, the Architecture description of an Inode implies that persisting a write-to-disk requires persisting the &quot;INode&quot;. INodes are persisted in etcd.
Which means your entire cluster&#x27;s write-to-disk throughput is limited to what you can push through a Raft consensus algorithm.<p>Look, there are all kinds of reasons one could legitimately decide that none of the existing scalable block storage systems satisfy your use case. Maybe containers really are different enough from VMs. But the blog post claims that there just <i>aren&#x27;t</i> any solutions; the research papers cited in the Documentation page are mostly old and are about systems in a very different part of this sub-space; and what developer documentation exists does not encourage me that this is a good idea.<p>Granted, I&#x27;ve been working on Ceph for 7 years and am a bit of a snob as a result.