Re: [PATCH 0/2] New zoned loop block device driver

[Christoph Hellwig <hch@lst.de>]

On Mon, Jan 06, 2025 at 10:38:24AM -0700, Jens Axboe wrote:
> > just not on the same page.  I don't know anything existing and usable,
> > maybe I've just not found it?
> 
> Not that I'm aware of, it was just a suggestion/thought that we could
> utilize an existing driver for this, rather than have a separate one.
> Yes the proposed one is pretty simple and not large, and maintaining it
> isn't a big deal, but it's still a new driver and hence why I was asking
> "why can't we just use ublk for this". That also keeps the code mostly
> in userspace which is nice, rather than needing kernel changes for new
> features, changes, etc.

Well, the reason to do a kernel driver rather than a ublk back end
boils down to a few things:

 - writing highly concurrent code is actually a lot simpler in the kernel
   than in userspace because we have the right primitives for it
 - these primitives tend to actually be a lot faster than those available
   in glibc as well
 - the double context switch into the kernel and back for a ublk device
   backed by a file system will actually show up for some xfstests that
   do a lot of synchronous ops
 - having an in-tree kernel driver that you just configure / unconfigure
   from the shell is a lot easier to use than a daemon that needs to
   be running.  Especially from xfstests or other test suites that do
   a lot of per-test setup and teardown
 - the kernel actually has really nice infrastructure for block drivers.
   I'm pretty sure doing this in userspace would actually be more
   code, while being harder to use and lower performance.

So we could go both ways, but the kernel version was pretty obviously
the preferred one to me.  Maybe that's a little biasses by doing a lot
of kernel work, and having run into a lot of problems and performance
issues with the SCSI target user backend lately.