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

[Amar Tumballi]

UPDATE:

Most of the plumbing work for new protocol for GlusterFS 4.0 is now done.
Considering its a lot of code, there is scope for cleanup in terms of
reducing duplicate code etc, but we would like to take them up post 4.0
branching.

Some of the main patches, which needs your review and merging help are:

* https://review.gluster.org/18850 : new iatt (for statx() support for
future, but also to keep the backward compatibility).
* https://review.gluster.org/18768 : Changes to common RPC structure, can
be used to send more info in every frame (fop) passed over. Currently adds
create-time of the flag.
* https://review.gluster.org/19096 : Adding more APIs to dict (so that
IATT/UUID can be sent on wire properly).
* https://review.gluster.org/19095 : To modify fop XDRs to add iattx and
new dict format in every fop.
* https://review.gluster.org/19098 : add all the new fops in protocol
xlators. (mostly copy paste and basic modifications).

With these patches merged, the protocol will be brand new, and also will be
backward compatible with 3.x version (both client and server). I request
people concerned with protocol to review these patches, and get them merged
before Jan 15th for branch-out.

Regards,
Amar




On Fri, Aug 11, 2017 at 6:04 PM, Amar Tumballi <atumball at redhat.com> wrote:

> 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.
>
> STATUS: GREEN
>
>    - 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.
>
> STATUS: YELLOW
>
>    - 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.
>
> STATUS: RED
>
> (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
> itself).
>
>    - fadvise()
>
> As per the email thread http://lists.gluster.org/
> pipermail/gluster-devel/2017-August/053457.html, if we implement the fop,
> we would need a new XDR for it.
>
> STATUS: RED
>
> (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.
>
> STATUS: RED
>
> (Mainly because the work is about discovery and changing the fops
> signature itself).
>
>
> 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.
>
>
> Regards,
>
> Amar
>
>
> --
> Amar Tumballi (amarts)
>



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