Re: [Nbd] [PATCH] define error values as part of the protocol

[Paolo Bonzini <pbonzini@...696...>]

On 14/05/2015 13:02, Wouter Verhelst wrote:
>> I don't think so.  Let the client worry about it.  They can always
>> decide to disconnect if they get ENOMEM, or they can get into a recovery
>> mode with some kind of exponential backoff, or...
> 
> Yeah, but then that's not what I meant with "fatal". I suppose I
> should've been clearer.
> 
> What I meant was, I can see two kinds of ENOMEM with your proposal:
> - The client sent out a request which was way too large. By reducing the
>   request size and retrying, or by waiting until a few outstanding
>   requests have finished, or a similar strategy, the client should be
>   able to get the request to succeed. The error is not impossible to
>   recover from, thus is not "fatal".
> - The client sent out a write request to a copy-on-write server or
>   similar, which gets ENOSPC (or some such) from the write() call when
>   attempting to write something to the backend. There is no storage
>   left, and recovery would probably require administrator intervention.
>   The error is not possible to recover from, hence the request is
>   "fatal", in that all future writes will most likely return the same
>   error.

This would be an ENOSPC.

For ENOMEM I meant something that is really an ENOMEM, for example a
malloc() failure.  This should not happen for a dumb server that can
support arbitrarily large requests by reading 128K, writing them,
reading 128K, writing them etc.

But a copy-on-write server most likely has to do malloc() in order to
implement all its magic, and then it may happen that it gets out of
memory and wants to return ENOMEM on the wire.

> For a client to be able to do something useful with an error message, it
> should know what the error message means. I'm afraid that with this
> proposal, that isn't the case.

I think this was miscommunication.

Paolo

>> And of course the server can always exit(1) if malloc returns NULL.
> 
> Yes, well, there's that too.
> 
>> Sticking policy into the protocol sounds like a road to people thinking
>> they must be an exception and not following the documentation.
> 
> True enough.
>