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

[Jens Axboe <axboe@kernel.dk>]

On 1/6/25 11:05 AM, Christoph Hellwig wrote:
> 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

That's certainly true.

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

Like I replied to Damien, that's mostly a bogus argument. If you're
doing sync stuff, you can do that with a single system call. If you're
building up depth, then it doesn't matter.

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

This is always true when it's a new piece of userspace, but not
necessarily true once the use case has been established.

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

That's very handwavy...

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

Sure, that is understandable.

-- 
Jens Axboe