Description of problem: lock/unlock fops should be handled differently than regular fops so as to make sure that a deadlock between the followers does not arise. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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/