search for: 7ff2e45e

On Mon, Apr 22, 2019 at 07:50:22PM -0500, Eric Blake wrote: > Previously, we were squashing EOVERFLOW into EINVAL; continue to do so > at points in the protocol where the client may not be expecting > EOVERFLOW. > > Signed-off-by: Eric Blake <eblake@redhat.com> > --- > server/protocol.c | 16 ++++++++++------ > 1 file changed, 10 insertions(+), 6 deletions(-) >

...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_RE...

...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_F...