[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 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: