Re: [Nbd] proposal

[Alex Bligh <alex@...872...>]

> That sounds like something that could be done in the negotiation phase,
> during the option haggling. I don't think I'd like to see this
> afterwards.

+1. Not least because the client by then is the kernel.

> > - NBD_ELABORATE_ON_ERROR
> >  if a command fails, an error code is returned. afaik this is an errno
> > value. sometimes you want to elaborate on this. for example a
> > server-device which detected that the datastructures got invalid or so
> > me return EINVALID (or whatever) and in response to this command a
> > textual description of what is wrong: "datastore corrupt, run fsck"
>
> Yes, there're definite problems with the current error handling.

+1 :-)

In particular error handling of reads is fundamentally broken as
per a previous message to this list.

> I
> didn't realize it at the time when I suggested it, but the absolute
> value of errno is very ill defined; POSIX only defines the symbolic
> names, nothing more, and on Linux the actual value can even be different
> from one architecture to another.

Wow, didn't know that.

> I've been thinking of creating an NBD-specific list of error values, so
> that a client can have some more useful information.
>
> Adding textual info could also be an interesting idea, but the only
> problem I see with that is that it would entail a change of the
> protocol. Currently, an error returns only the nbd_reply data, nothing
> more; if we want to add textual data to that, it would require adding a
> length field, followed by an amount of textual data to the reply. This
> is doable, I suppose, but would change the protocol incompatibly.

I think it might need to change anyway (see reads).

My problem with ELABORATE_ON_ERROR is "on which error?". An error
does not indicate the end of the protocol session, and a whole
string of errors could be produced asynchronously. Does the server
have to store them up just in case the client wants later elaboration?
If so, for how long?

The only sensible thing to do is to send the error with the response.

The errors also should be machine parsable. Perhaps borrow someone
else's well-defined error codes which are like POSIX. NFS perhaps?

--
Alex Bligh