[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



On Thu, May 14, 2015 at 01:34:12PM +0200, Paolo Bonzini wrote:
> 
> 
> 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.

Indeed (except that the error for a read request comes before the data,
making error handling difficult, but that's a different matter
entirely).

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

Ah, okay, that way. Right.

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

Looks like it. Applied, thanks.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26



Reply to: