4 ms·

> Ublk has a lot of interesting potential, but the current use cases for it are not entirely clear. I've seen a couple of FUSE filesystems that don't implement

> Ublk has a lot of interesting potential, but the current use cases for it are not entirely clear. I've seen a couple of FUSE filesystems that don't implement a full filesystem, instead implementing the minimum required for a file to exist which itself can have any other filesystem created within it and loop-mounted. Notably a couple that use S3 as the backing store. This means you get to use a different storage mechanism without losing the semantics of your preferred filesystem. If you have a user case for this (for one it could simplify integrating a new storage service into your infrastructure) then there is a use case for ublk: it achieves the same but more efficiently.

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).

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).