[Gluster-Maintainers] Proposed Protocol changes for 4.0: Need feedback.

Amar Tumballi atumball at redhat.com
Fri Aug 11 12:34:36 UTC 2017

Hi All,

Below are the proposed protocol changes (ie, XDR changes on the wire) we
are thinking for Gluster 4.0.

   - rchecksum/fsetattr: Add 'gfid' field on wire

Basic work already done at https://review.gluster.org/#/c/3956/ .
Considering its 5yrs old patch, I refreshed it at
https://review.gluster.org/17656 for experimental branch, and it is all
working fine.

This patch also helps in creating new RPC program etc, so for all other XDR
changes, we only need to handle the specific change in the patch.


   - statx() support

https://github.com/gluster/glusterfs/issues/273 talks more on it. We can
consider to make XDR changes for sure even if we don't implement the fops
in all other xlator IMO, so there won't be clients' compatibility issue.

STATUS: RED  (As no work has been started yet)

   - Changes to 'gf_flock' structure on wire

More on it @ https://review.gluster.org/#/c/15698. Can be handled without
this change by using xdata, but adding this field in the XDR will make it
faster, and less error prone.


   - Changes in few of the 'fops' to get struct iatt in _cbk

This is needed for mainly handling the cases of fail over during rebalance,
self-heal etc. Today, because we don't have a protocol support, our cross
architecture compatibility is broken, mainly because we send iatt as binary
in xdata dict, which is not desirable.


(Red as we need to hear from team on what are the changes needed, and it
would be significant change as we may have to change the fops signature

   - fadvise()

As per the email thread
if we implement the fop, we would need a new XDR for it.


(It is red as it is still in discovery phase)

   - Misc

We don't have any other proposal for protocol change for now, other than a
suggestion from Jeff Darcy about taking out the common flags we use across
the board, inside xdata, and make them as 'flags' itself in XDR, for better
perf, and manageability.


(Mainly because the work is about discovery and changing the fops signature

This is the good time to highlight if you need any further changes in
protocol itself, and start towards getting it implemented and tested. I
volunteer to review all such patches, and happy to co-ordinate it on
experimental branch before sending them as a single patch (or multiple
dependent, granular patches) on master when we feel it is ready.



Amar Tumballi (amarts)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20170811/f5a741df/attachment.html>

More information about the maintainers mailing list