Bug 826982 - Inconsistent handling of xdata in lookup_cbk of protocol/client
Inconsistent handling of xdata in lookup_cbk of protocol/client
Status: CLOSED CURRENTRELEASE
Product: GlusterFS
Classification: Community
Component: core (Show other bugs)
3.3.0
Unspecified Unspecified
low Severity medium
: ---
: ---
Assigned To: Amar Tumballi
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-31 07:13 EDT by Xavier Hernandez
Modified: 2013-12-18 19:08 EST (History)
2 users (show)

See Also:
Fixed In Version: glusterfs-3.4.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-24 13:32:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Xavier Hernandez 2012-05-31 07:13:13 EDT
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.
Comment 1 Amar Tumballi 2012-05-31 08:14:33 EDT
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.
Comment 2 Xavier Hernandez 2012-05-31 10:01:55 EDT
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.
Comment 3 Amar Tumballi 2012-05-31 12:48:13 EDT
That is changed with http://review.gluster.com/3437 (check the code in git master branch).
Comment 4 Amar Tumballi 2012-07-05 04:08:38 EDT
http://review.gluster.com/3633 should address your concerns, once merged upstream, will mark the bug closed.
Comment 5 Xavier Hernandez 2012-07-05 05:41:30 EDT
Thanks. It seems to solve the problem and it will be very useful.
Comment 6 Vijay Bellur 2012-07-12 21:10:32 EDT
CHANGE: http://review.gluster.com/3633 (protocol/server: return 'xdata' even in case of error) merged in master by Anand Avati (avati@redhat.com)

Note You need to log in before you can comment on or make changes to this bug.