Description of problem: Not sure if this is really a bug or an undefined behavior. The protocol/client translator always propagates the xdata argument in all FOP callbacks even if op_ret is -1. However, lookup_cbk leaves xdata set to NULL in case of error. It would be very interesting to be able to send extra error information in xdata when an error is detected by a server translator. Version-Release number of selected component (if applicable): 3.3.0 How reproducible: From a server translator, fill an xdata with some info and call STACK_UNWIND with this xdata and op_ret set to -1. When this callback is received on the client side, all FOPS will receive the xdata, except lookup. Actual results: xdata is correct on all FOP callbacks but lookup_cbk, on which it is NULL. Expected results: xdata on lookup_cbk should have the correct value set by the server translator.
One of the design idea with GlusterFS xlator fop APIs was that if 'op_ret' is -1, then all arguments should be ignored (other than op_errno). This is because there is no restriction that a _CBK() is returning NULL for failures. It can be 'junk'. That way, we are treating even xdata as possible junk if op_ret is -1, so not passing it across the wire. If there is a proper usecase, we need to change the behavior across the board.
Currently, all FOPS in protocol/server always serialize xdata content and send it through the network, regardless of whether an error has occurred or not. Even all FOPS in protocol/client unserialize it unconditionally. The only exception is lookup_cbk. This seems to mean that the intended behavior is that xdata is always transmited and that lookup_cbk has a bug (xdata has been sent across the network, but ignored later). I think that allowing to use xdata even in the case of an error could be very useful to report extended error information not to the end application but to an intermediate translator. This could allow us to build more intelligent translators that could react better to some error circumstances.
That is changed with http://review.gluster.com/3437 (check the code in git master branch).
http://review.gluster.com/3633 should address your concerns, once merged upstream, will mark the bug closed.
Thanks. It seems to solve the problem and it will be very useful.
CHANGE: http://review.gluster.com/3633 (protocol/server: return 'xdata' even in case of error) merged in master by Anand Avati (avati)