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 13:02:18 +0200
- Message-id: <20150514110218.GE20175@...3...>
- In-reply-to: <55547BB8.4030005@...696...>
- References: <1431014292-24645-1-git-send-email-pbonzini@...696...> <20150514102515.GA20175@...3...> <55547BB8.4030005@...696...>
On Thu, May 14, 2015 at 12:40:56PM +0200, Paolo Bonzini wrote:
>
>
> On 14/05/2015 12:25, Wouter Verhelst wrote:
> > Also, we should indeed stick to errno numbers for backwards
> > compatibility, but there's no reason why we wouldn't be able to create a
> > separate set of numbers (with a high bit set, e.g.) for errors that
> > can't be properly expressed with errno numbers, and I'm not sure if
> > mapping ENOMEM in this manner is a good idea.
>
> Right. But ENOMEM technically could have happened before.
>
> > As to whether ENOMEM should be a fatal message in the protocol or not?
> > Not sure.
>
> 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.
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.
> 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.
--
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: