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

OTOH, for backcompat reasons it is reasonable to state that older versions of nbd-server could send pretty much anything over the wire[1], and that clients should therefore treat any nonzero value as an unknown error. I think that might also be a correct way to deal with error numbers in cases where the client does not know what to do with it. [1] I originally thought that errno values were way more standardized than they happen to be in practice, and so the initial error handling in nbd-server just sent the value of errno, whatever it happened to be, over the wire. That worked just fine if client and server were the same platform -- and more so since all the client would ever do when it saw an error was yell "the server sent error code X" and abort, so that the actual error number didn't even matter -- but it obviously wasn't ideal; and when we chose the error values that got written in stone, we chose the errno values that Linux/x86 uses for the types of errors that seemed reasonable. What older servers sent is however not really defined, and therefore should be treated as nasal daemons. [...] > 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. Indeed; I think that is what we should do. > 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). I think we can say that, but we should definitely also say that a client should treat unknown errors in a particular way. Possibly "abort the connection and give up", but something.