> 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.
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.
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).
Just today, I finally had the hardware in place to fire up my 10-year-old ZFS array.
It used to be my daily driver, but three moves across country and small living spaces pushed this storage box down in urgency; I regressed back to my old bad habits of haphazard disks and flash drives and usb "thumb" drives... all over...
Anyhow, tried to import the ZFS pool, crashed ZFS, caused a kernel panic. Dang.
Switched to a recent FreeBSD distribution, same crash.
I'm pulling together the various methods of recovery from folks who've seen this type of failure, and all will be well. (Or if not, I've got at least one good snapshot up on Backblaze.)
But user space for something like this sounds like the perfect fit. ZFS already subsumes functions from device driver to blocks and files manager, on up to volumes and snapshots-- the whole storage stack. Those user-facing aspects of storage and volume management could reasonably be taken as a user space process tree, where a crash wouldn't bring down your entire server.
Heck, to triage my problem, it's suggested to re-run the zpool import with other options. If I could iterate and converge on a operational set of recovery steps, without taking my entire server out and back up from cold boot, yeah that would be great!
From what little I understand, GNU Hurd heavily emphasises its aspect of everything being a filesystem and that filesystem having a user-level driver. This is not, AFAIK, not an inherent consequence of microkernels in general.
I'm quite surprised a new API like this got merged without a clear (public) indication for why it was needed. Given that Linux commits to never breaking user-space, I'd imagine adding this new feature incurs a substantial and near-permanent cost in terms of maintenance, security, etc.
Is the mental model for this to treat it like a device driver (where it's off by default and can be turned on under specific circumstances), or is this thought of as part of the default-available kernel API that every system will have access to from now on? (I guess FUSE itself is a little fuzzy in this respect)
I'm not. It's a wet dream for any company that wants to do distributed block storage but doesn't want to update kernel module every time the new feature or fix gets added; nowadays a lot of that (like Ceph's RBD driver) needs to be in kernel, and it would need to be backported any time new feature that client wants would come along.
The code is tiny compared to full implementation of any of the block drivers and allows them to be moved to userspace so it also potentially saves a lot of maintenance in the future, because it would be the first choice if you're implementing another distributed block file system.
> Is the mental model for this to treat it like a device driver (where it's off by default and can be turned on under specific circumstances), or is this thought of as part of the default-available kernel API that every system will have access to from now on? (I guess FUSE itself is a little fuzzy in this respect)
As a device driver that can be fully tested with no actual hardware, and much smaller area of attack than real driver.
> Ublk has a lot of interesting potential, but the current use cases for it are not entirely clear.
I wonder how long it'll be before someone merges a cleaner set of APIs for user space drivers to go with this. Android has already built out their own parallel feature for this though I don't think it'd fly for the rest of the kernel given how closely integrated it is. Neat nonetheless :)
I think they resist that mainly because it makes it easier for companies that don't want to upstream their drivers, and nobody else.
Currently, if there is say a better, more efficient way to do some common task ,say storage drivers, do, you can just go in and refactor all of that.
With common interface, you're doomed. You might implement the better way and give it in API, but you can't force anyone to use it, and you can't deprecate the old one.
You also have to keep the old behaviour *forever*, even for things that "do not break userspace" so it's even bigger maintenance burden.
And what if your API is wrong ? Still gotta keep it... and someone might still use it and trip on the wrongness
Android nowadays is a kind of pseudo-microkernel, as since Android 8 all new drivers are required to be Treble based, and they call "legacy" to classical Linux kernel drivers.
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.