Bug 1158628 - [FEAT] Add GF_FOP_IPC for inter-translator communication
Summary: [FEAT] Add GF_FOP_IPC for inter-translator communication
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: core
Version: mainline
Hardware: All
OS: All
unspecified
medium
Target Milestone: ---
Assignee: Jeff Darcy
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-29 18:14 UTC by Jeff Darcy
Modified: 2015-05-14 17:44 UTC (History)
2 users (show)

Fixed In Version: glusterfs-3.7.0
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-05-14 17:28:14 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)

Description Jeff Darcy 2014-10-29 18:14:19 UTC
From the proposed patch:

Several features - e.g. encryption, erasure codes, or NSR - involve
multiple cooperating translators which sometimes need a "private" means
of communication amongst themselves.  Historically we've used virtual or
synthetic xattrs, but that's not very elegant and clutters up the
getxattr/setxattr path which must also handle real xattr requests.  This
new fop should address that.

Comment 1 Anand Avati 2014-10-29 18:14:48 UTC
REVIEW: http://review.gluster.org/8812 (every/where: add GF_FOP_IPC for inter-translator communication) posted (#3) for review on master by Jeff Darcy (jdarcy@redhat.com)

Comment 2 Anand Avati 2015-03-01 08:13:38 UTC
REVIEW: http://review.gluster.org/8812 (every/where: add GF_FOP_IPC for inter-translator communication) posted (#4) for review on master by Venky Shankar (vshankar@redhat.com)

Comment 3 Anand Avati 2015-03-05 17:30:05 UTC
REVIEW: http://review.gluster.org/8812 (every/where: add GF_FOP_IPC for inter-translator communication) posted (#5) for review on master by Venky Shankar (vshankar@redhat.com)

Comment 4 Anand Avati 2015-03-10 16:29:49 UTC
REVIEW: http://review.gluster.org/8812 (every/where: add GF_FOP_IPC for inter-translator communication) posted (#6) for review on master by Jeff Darcy (jdarcy@redhat.com)

Comment 5 Anand Avati 2015-03-11 00:19:03 UTC
REVIEW: http://review.gluster.org/8812 (every/where: add GF_FOP_IPC for inter-translator communication) posted (#7) for review on master by Jeff Darcy (jdarcy@redhat.com)

Comment 6 Anand Avati 2015-03-17 14:02:25 UTC
COMMIT: http://review.gluster.org/8812 committed in master by Vijay Bellur (vbellur@redhat.com) 
------
commit 0d2bed70faed3c63f25ed9269dc55562973ef9b7
Author: Jeff Darcy <jdarcy@redhat.com>
Date:   Tue Mar 10 20:14:47 2015 -0400

    every/where: add GF_FOP_IPC for inter-translator communication
    
    Several features - e.g. encryption, erasure codes, or NSR - involve
    multiple cooperating translators which sometimes need a "private" means
    of communication amongst themselves.  Historically we've used virtual or
    synthetic xattrs, but that's not very elegant and clutters up the
    getxattr/setxattr path which must also handle real xattr requests.  This
    new fop should address that.
    
    The only argument is an int32_t "op" which should be recognized by the
    target translator.  It is recommended that translators using these
    feature follow some convention regarding the ops that they define, to
    avoid conflicts.  Using a hash of the target translator's type string as
    a base for a series of ops would probably be a good start.  Any other
    information can be passed in both directions using xdata.
    
    The default behavior for this fop, as with any other, is to pass through
    to FIRST_CHILD.  That makes use of this fop "transparent" to other
    translators that were written before it existed, but it also means that
    it only really works with pass-through translators.  If a routing
    translator (such as DHT) or a fan-out translator (such as AFR) is
    involved, the IPC might not reach its intended destination unless those
    translators are modified to forward IPC fops along all paths.
    
    If an IPC gets all the way to storage/posix it is considered an error,
    much like an uncaught exception.  We don't actually *do* anything in
    that case, but we do log it send back an EOPNOTSUPP error.  This makes
    the "unrecognized opcode" condition distinguishable from the "no IPC
    support" condition (which would yield an RPC error instead) so clients
    can probe for the presence of a handler for their own favorite opcode
    and either use that or use old-school xattrs depending on the result.
    
    BUG: 1158628
    Signed-off-by: Venky Shankar <vshankar@redhat.com>
    Signed-off-by: Jeff Darcy <jdarcy@redhat.com>
    Change-Id: I84af1b17babe5b30ec03ecf027ae37d09b873968
    Reviewed-on: http://review.gluster.org/8812
    Reviewed-by: Vijay Bellur <vbellur@redhat.com>

Comment 7 Niels de Vos 2015-05-14 17:28:14 UTC
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.0, please open a new bug report.

glusterfs-3.7.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user

Comment 8 Niels de Vos 2015-05-14 17:35:40 UTC
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.0, please open a new bug report.

glusterfs-3.7.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user

Comment 9 Niels de Vos 2015-05-14 17:38:02 UTC
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.0, please open a new bug report.

glusterfs-3.7.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user

Comment 10 Niels de Vos 2015-05-14 17:44:21 UTC
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.0, please open a new bug report.

glusterfs-3.7.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user


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