Re: [Nbd] [PATCH] define error values as part of the protocol
- To: Paolo Bonzini <pbonzini@...696...>
- Cc: nbd-general@...72...
- Subject: Re: [Nbd] [PATCH] define error values as part of the protocol
- From: Wouter Verhelst <w@...112...>
- Date: Thu, 14 May 2015 14:17:24 +0200
- Message-id: <20150514121724.GF20175@...3...>
- In-reply-to: <55548834.1060606@...696...>
- References: <1431014292-24645-1-git-send-email-pbonzini@...696...> <20150514102515.GA20175@...3...> <55547BB8.4030005@...696...> <20150514110218.GE20175@...3...> <55548834.1060606@...696...>
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: