Re: [Libguestfs] [nbdkit PATCH 3/7] RFC: protocol: Only send EOVERFLOW when valid

[adding NBD list] On 4/23/19 2:36 AM, Richard W.M. Jones wrote: Context: nbdkit previously did not allow the EOVERFLOW value over the wire, so I'm proposing a patch to nbdkit to support it. But it raises the question on whether allowing EOVERFLOW to any arbitrary command is okay, or whether EOVERFLOW should only be exposed over the wire to a client that is likely to expect it. The NBD spec added EOVERFLOW as a valid error value when commit 7ff2e45e (Apr 2016) promoted structured replies to be part of the protocol, so any client that negotiates structured replies is thus new enough to expect EOVERFLOW; conversely, EOVERFLOW is only documented as being reasonable for the server to send in response to a client using NBD_CMD_FLAG_DF to NBD_CMD_READ (again, which implies the client negotiated structured replies), and not all clients support structured replies. See also my recent thread about the potential of adding ENOTSUP as a valid error, towards the end of the message: https://lists.debian.org/nbd/2019/03/msg00007.html There, I argued that since clients do not have to have a 1:1 mapping from system errno values to NBD wire error values, that any addition of a new error value over the wire should at least think about back-compat considerations, where we should consider documenting that a server SHOULD NOT send the new error except to clients that are obviously new enough to be aware that the error is possible. I intentionally used SHOULD NOT rather than MUST NOT, as a server may still choose to expose non-standard errors over the wire if a client might benefit from those errors, and a well-written client will squash non-standard errors received over the wire back to EINVAL. So the question at hand is whether I should patch the NBD spec to recommend that a server SHOULD NOT send EOVERFLOW except in response to NBD_CMD_READ when the NBD_CMD_FLAG_DF bit is set (similar to my proposed wording that a server SHOULD NOT send ENOTSUP except in response to NBD_CMD_FLAG_FAST_ZERO). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org