betawaffle

5 ms·

1.
by betawaffle 5y ago
also zig and go-nuts
2.
by betawaffle 9y ago
Why can't we get hype for my friend Sparse Merkle Trees!
3.
by betawaffle 9y ago
You don't need to trust the third parties, that's the point.
4.
by betawaffle 9y ago
I'm just going to leave this here: https://aviation.stackexchange.com/questions/19569/how-many-...
5.
by betawaffle 10y ago
These are very good points, but also probably much more constructive as GitHub issues, where they can be either answered or addressed. In the meantime, hopefully I can talk to a few of these: >haven't figured out consistency yet I d
6.
by betawaffle 10y ago
Torus implements a kind of MVCC, yes. As for read-many-to-write-one, I assume you're talking about Reed-Solomon or similar erasure coding? There have been some papers written about ways to reduce that, a good one is from Facebook: htt
7.
by betawaffle 10y ago
Nope, previous block versions get GC'd. I don't see how LBAs have any relevance here... you're talking about a much lower layer than what Torus is operating on.
8.
by betawaffle 10y ago
The "interface" we're exporting is very different from the underlying storage. The block device interface we currently provide supports random writes just fine, but the underlying storage we use (which involves memory-mapped
9.
by betawaffle 10y ago
Torus is append-only too. We also plan to support something more like what Facebook's paper describes, where they have extra parity (xor) to support more efficient local repair.
10.
by betawaffle 10y ago
Block devices (and NBD specifically) absolutely have a notion of sync(). We use sync() as the unit of write visibility. All writes up until a sync are effectively anonymous until a sync().
11.
by betawaffle 10y ago
We had a POSIX interface early on (via FUSE), but decided to expose a a block storage interface first instead. This is not a "filesystem", it's a storage abstraction, and we've spent more than 6 months on it. Seems like