Bug 1333370

REVIEW: http://review.gluster.org/14226 (jbr/locking: Define path for lock/unlock fops in JBR) posted (#1) for review on master by Avra Sengupta (asengupt)

REVIEW: http://review.gluster.org/14226 (jbr/locking: Define path for lock/unlock fops in JBR) posted (#2) for review on master by Avra Sengupta (asengupt)

REVIEW: http://review.gluster.org/14226 (jbr/locking: Define path for lock/unlock fops in JBR) posted (#3) for review on master by Avra Sengupta (asengupt)

REVIEW: http://review.gluster.org/14226 (jbr/locking: Define path for lock/unlock fops in JBR) posted (#4) for review on master by Avra Sengupta (asengupt)

REVIEW: http://review.gluster.org/14226 (jbr/locking: Define path for lock/unlock fops in JBR) posted (#5) for review on master by Avra Sengupta (asengupt)

COMMIT: http://review.gluster.org/14226 committed in master by Jeff Darcy (jdarcy) 
------
commit c137f6a7389d7f760e4724f3506180f9cfc0da52
Author: Avra Sengupta <asengupt>
Date:   Mon May 16 14:55:54 2016 +0530

    jbr/locking: Define path for lock/unlock fops in JBR
    
    lock/unlock fops need to be handled differently than
    other 'regular' fops, so as to avoid chances of deadlock
    in blocking calls. This patch addresses the same in the
    following manner, with a caveat.
    
    1. On receiving the fop if the node is a follower, it
       performs the operation (irrespective of it being
       lock/unlock fop), and returns the result.
    
    2. If the node is a leader it follows the following paths
       for lock and unlock fops:
    
       For lock fops :
       -> It performs the fop on itself. If it is a failure, it
          sends -ve ack to the client. If it is successful, it
          dispatches the fop to the followers.
       -> On receiving responses from the followers, it checks
          for quorum (including the leader's outcome). If
          quorum is met, it sends +ve ack to the client.
       -> If quorum is not met, then it *should* issue a rollback
          to the followers, followed by the rollback on the leader.
          It should then send -ve ack to he client.
    
       For unlock fops:
       -> It dispatches the fop on the followers first.
       -> On receiving responses from the followers, it performs
          the fop on itself. On completion, it checks for quorum
          (including the leader's outcome). If quorum is met, it
          sends +ve ack to the client.
       -> If quorum is not met, then it *should* issue a rollback
          on itslef, followed by the rollback on the followers.
          It should then send -ve ack to he client.
    
    Caveat:
       -> jbr-server does not have a rollback framework yet,
          and hence this patch does not perform the rollbacks as
          discussed in the failure scenarios above. The rollback
          framework will be a different dependent patch.
    
    Change-Id: I26961b27cb85f324c1ffeee80e82ec082ffa4465
    BUG: 1333370
    Signed-off-by: Avra Sengupta <asengupt>
    Reviewed-on: http://review.gluster.org/14226
    Smoke: Gluster Build System <jenkins.com>
    NetBSD-regression: NetBSD Build System <jenkins.org>
    CentOS-regression: Gluster Build System <jenkins.com>
    Reviewed-by: Jeff Darcy <jdarcy>

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.9.0, please open a new bug report.

glusterfs-3.9.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://lists.gluster.org/pipermail/gluster-users/2016-November/029281.html
[2] https://www.gluster.org/pipermail/gluster-users/