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