Re: [PATCH v4] doc: Add alternate trim/zero limits
On 05/03/2018 11:02 AM, Eric Blake wrote:
On 05/03/2018 10:55 AM, Eric Blake wrote:
for BLOCK_STATUS, when we use it in some copying process, it's good
to query large region, to be able to use fast path in case of zero
area (I don't remember, did we finally allowed last chunk of
BLOCK_STATUS to exceed requested region?)
We talked about that. It is NOT currently worded in the spec that
way, but I think the qemu implementation (which is the only known
implementation of BLOCK_STATUS right now) will tolerate it, so now
would be a good time to wordsmith that addition into the standard.
Clarification: the qemu client implementation will tolerate a server
that does that, although qemu as the server does not currently do that.
And I stand corrected - as released, qemu 2.12 does NOT tolerate a
server sending extra:
if (extent->length == 0 ||
(client->info.min_block && !QEMU_IS_ALIGNED(extent->length,
client->info.min_block)) ||
extent->length > orig_length)
{
error_setg(errp, "Protocol error: server sent status chunk with "
"invalid length");
return -EINVAL;
However, that client always sends NBD_CMD_FLAG_REQ_ONE; so we do have a
bit of an out by stating that the server can reply with extra
information in the last extent if the flag was not set (and when the
flag IS set, the client is being pickier about exactly one extent).
I'll propose wordings.
The idea is that if we want to allow servers to do that, then portable
clients need to be prepared for it to happen, and the longer we go
without documenting that a server may send an overlarge final extent,
the more likely that a client will be implemented that chokes on such a
server, making it harder to add to the spec at a later date.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Reply to: