Re: [Libguestfs] [PATCH nbdkit] Minimal implementation of NBD Structured Replies.
On 3/8/19 10:05 AM, Richard W.M. Jones wrote:
On Fri, Mar 08, 2019 at 09:03:05AM -0600, Eric Blake wrote:
> On 3/8/19 4:04 AM, Richard W.M. Jones wrote:
>> Also we do not understand NBD_CMD_FLAG_DF, but that seems to be OK
>> because (a) we don't advertize the feature and (b) we only send back a
>> single chunk anyway.
>
> Or, we COULD advertise it because we always honor it (but that's a
> larger diffstat, and thus at odds with "minimal implementation"). Either
> way works.
What's also unclear to me is how NBD_CMD_FLAG_DF interacts with
NBD_CMD_BLOCK_STATUS. What does it mean for extents which are by
their nature fragmented?
FLAG_DF can only be requested for NBD_CMD_READ. It requires the server
to advertise that it is supported before the client can use it (we could
advertise it now while we don't have sparse reads, but we'd have to be
more careful once we do figure out how plugins can do fragmented reads).
Part of the reason that it is advertised is that NBD_CMD_READ is
pre-existing, so we didn't want to break existing servers not expecting
a new flag.
FLAG_REQ_ONE can only be requested for NBD_CMD_BLOCK_STATUS. It does not
require the server to advertise support: the client can blindly use it,
because all known servers that implement BLOCK_STATUS can easily support
it, and because BLOCK_STATUS is new, we can expect all future
implementations to be able to comply without the worry of back-compat
that CMD_READ has. Note that since we still don't negotiate any
contexts, we don't have to worry about it, yet.
There's no command where you can mix the two flags (even though they
have distinct bit values); setting both flags should fail with -EINVAL
due to a non-permitted flag for the given command.
Hopefully that helps.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 488 bytes)