Re: Linux kernel NBD driver support for structured replies?
On Tue, Sep 07, 2021 at 04:35:13PM -0500, Eric Blake wrote:
> On Tue, Sep 07, 2021 at 02:19:32PM -0700, Josh Triplett wrote:
> > I'm currently using the NBD client driver in the Linux kernel. At some
> > point, I'd be interested in adding support for structured replies,
> > specifically so that an NBD server can efficiently handle ranges of
> > zeroes (e.g. "for the 4k block you asked for, here are 200 bytes of
> > data, and the rest if zero").
>
> I don't know if you'll get the granularity of 200 bytes given the
> nature of file system blocking, but it's definitely worth adding the
> support so that "for the 64k block you asked for, here are 4k of data
> and the rest is zero".
I'm hoping to make the client capable of handling byte granularity. As
far as I can tell, the spec allows this; NBD_REPLY_TYPE_OFFSET_DATA and
NBD_REPLY_TYPE_OFFSET_HOLE both take a length in bytes (not blocks). It
does say "each chunk MUST describe at least one byte, although to
minimize overhead, the server SHOULD use chunks with lengths and offsets
as an integer multiple of 512 bytes, where possible", but the initial
implementation I had in mind wouldn't actually benefit from that, and
since it's a "SHOULD" the client still needs to handle the
byte-granularity case.
I had planned to just accumulate the data in a buffer, and handle
NBD_REPLY_TYPE_OFFSET_HOLE with memset; that's still more efficient than
sending zeroes over the wire, and it'd always be possible to add more
efficiency later.
> It will also pay dividends if you also add support for querying the
> "base:allocation" meta context information, so that the kernel can
> then acurately implement lseek(SEEK_HOLE) and similar on an NBD
> device, since that also requires structured reply support.
For a first pass, I only planned to only support structured replies, not
contexts or metadata.
> > Does that seem reasonable to add to the kernel driver? I wanted to check
> > before considering development of a patch.
>
> I'm not aware of anyone else doing it yet (I haven't yet been brave
> enough to dive into implementing this in the kernel, although I have
> implemented it in user space in both qemu and libnbd). I'm certainly
> happy to help with integration testing, or give you tips on how to
> test it.
Thank you!
I'll check back when I start to implement it. Might be a while; I just
wanted to start the conversation early.
- Josh Triplett
Reply to: