3 ms·

Randomly seekable randomly writeable block storage wont be fast when implemented on top of any object store, especially ones that do not allow arbitrary append

by xani_ 4y ago

Randomly seekable randomly writeable block storage wont be fast when implemented on top of any object store, especially ones that do not allow arbitrary append like S3. Filesystems make a lot of assumptions for underlying storage. But this allows any typical block device driver to run in userspace which means you no longer require certain version of kernel to support new features or new protocol, which is nice. It's also useful in testing or prototyping filesystems, as you can make userspace proxy that can emulate any kind of error without much kernel knowledge. Sure, there are already some tools for that but it's easier to do in userspace.

dspillett 4y ago
No, bur for situations where writes are rare and/or tend to be in bulk (so you can perhaps buffer writes to avoid saving partial blocks and use variable sized blocks instead of always writing things in fixed-size blocks (though variable blocks implies some sort of index, that would need careful design to not be a massive source of contention particularly during write operations)) that effect is reduced. Everything is still very latency sensitive of course, even for reads, but still potentially usable. You could apply compression to the blocks and use a local S3 implementation so you now have a compressed block device upon which you can apply any filesystem: the S3 implementation will deal with managing the allocation and freeing of space reducing complexity and you now have a read/write compressed store (most compressed filesystems are make-once-then-read-only). Still not most efficient due to the extra layers, but the latency will be much lower due to locality and implementation of each layer is simpler because you need to make each aware of less (in fact you can use a pre-existing implementation for the filesystem and the object store).

by xani_ 4y ago

dspillett 4y ago

No, bur for situations where writes are rare and/or tend to be in bulk (so you can perhaps buffer writes to avoid saving partial blocks and use variable sized blocks instead of always writing things in fixed-size blocks (though variable blocks implies some sort of index, that would need careful design to not be a massive source of contention particularly during write operations)) that effect is reduced. Everything is still very latency sensitive of course, even for reads, but still potentially usable. You could apply compression to the blocks and use a local S3 implementation so you now have a compressed block device upon which you can apply any filesystem: the S3 implementation will deal with managing the allocation and freeing of space reducing complexity and you now have a read/write compressed store (most compressed filesystems are make-once-then-read-only). Still not most efficient due to the extra layers, but the latency will be much lower due to locality and implementation of each layer is simpler because you need to make each aware of less (in fact you can use a pre-existing implementation for the filesystem and the object store).