[Qemu-devel] structured reply behavior for read of 0 bytes

[Qemu-devel] structured reply behavior for read of 0 bytes

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1047 bytes --]

As currently written, structured reply is documented as:

> NBD_REPLY_TYPE_OFFSET_DATA (1)
> 
> This chunk type is in the content chunk category. length MUST be at least 9. It represents the contents of length - 8 bytes of the file, starting at the absolute offset from the start of the export.

which implies that the data size must be non-zero. But clients can
request a read of size 0 (the spec doesn't forbid it, but neither does
it define special semantics for it), and the existing qemu
implementation as of qemu commit f140e300 sends
NBD_REPLY_TYPE_OFFSET_DATA with length of 8 and no data payload if the
client requests a 0-byte read.  Should we specifically allow this
particular answer, or should a 0-length read be answered solely by
NBD_REPLY_TYPE_NONE, meaning that qemu's current behavior needs a tweak?
 Either way, I probably need another tweak to the NBD spec for
structured reads.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: [Qemu-devel] structured reply behavior for read of 0 bytes

[Wouter Verhelst]

Hi Eric,

On Fri, Nov 03, 2017 at 05:45:07PM -0500, Eric Blake wrote:
> As currently written, structured reply is documented as:
> 
> > NBD_REPLY_TYPE_OFFSET_DATA (1)
> > 
> > This chunk type is in the content chunk category. length MUST be at least
> > 9. It represents the contents of length - 8 bytes of the file, starting at
> > the absolute offset from the start of the export.
> 
> which implies that the data size must be non-zero. But clients can request a
> read of size 0 (the spec doesn't forbid it, but neither does it define
> special semantics for it), and the existing qemu implementation as of qemu
> commit f140e300 sends NBD_REPLY_TYPE_OFFSET_DATA with length of 8 and no data
> payload if the client requests a 0-byte read.  Should we specifically allow
> this particular answer, or should a 0-length read be answered solely by
> NBD_REPLY_TYPE_NONE, meaning that qemu's current behavior needs a tweak?
> Either way, I probably need another tweak to the NBD spec for structured
> reads.

I'd like to take a step back first and wonder what a zero-sized read
would actually mean. "Please read no data at this offset". What good
does that do? I can't see anything useful coming out of that.

If we can come up with some useful semantics that we could apply to a
zero-sized read, then I guess it makes sense to worry about handling it.
In the absense of that though, I think it is more appropriate to just
document that a client should not send it, but that a server's behaviour
upon such a command is not defined (other than that it should not cause
the server to quit, through a crash or otherwise).

In fact, the current spec, as you point out, already implicitly forbids
(with MUST) nonzero writes by requiring a data chunk to have nonzero
payload (and that can't happen when you have a zero-sized read). It
might make sense to make that explicit.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
     Hacklab

Re: [Qemu-devel] structured reply behavior for read of 0 bytes

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1815 bytes --]

On 11/05/2017 01:57 PM, Wouter Verhelst wrote:
> 
> I'd like to take a step back first and wonder what a zero-sized read
> would actually mean. "Please read no data at this offset". What good
> does that do? I can't see anything useful coming out of that.

If the export is some sort of memory-mapped device, where a read of 0
has a different action than a read of 1, then maybe it has use - but
that gets into the dirty details of a client and server that know what
to expect. I agree that in the generic case it's probably easiest to
just leave things as unspecified behavior results.

I know that a 0-byte write is an interesting probe - does that succeed
on a read-only export, even when a write of one byte fails?  But that
just strengthens the argument that normal clients won't be doing 0-byte
transactions.  It is also feasible that some client/server pair may want
to special-case a length of 0 as meaning 4G.

> 
> If we can come up with some useful semantics that we could apply to a
> zero-sized read, then I guess it makes sense to worry about handling it.
> In the absense of that though, I think it is more appropriate to just
> document that a client should not send it, but that a server's behaviour
> upon such a command is not defined (other than that it should not cause
> the server to quit, through a crash or otherwise).

I'll propose wording along those lines.

> 
> In fact, the current spec, as you point out, already implicitly forbids
> (with MUST) nonzero writes by requiring a data chunk to have nonzero
> payload (and that can't happen when you have a zero-sized read). It
> might make sense to make that explicit.
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]