On 5/11/19 5:51 PM, Wouter Verhelst wrote: > > 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. > I think enough existing clients just silently treat unknown server errors as EINVAL to make that worth specifying (as a SHOULD, rather than MUST), rather than aborting the connection. So I wend ahead and added this sentence on top of my other changes: +The client SHOULD treat an unexpected error value as if it had been +`NBD_EINVAL`, rather than disconnecting from the server. + -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature