| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@redhat.com>
Reviewed-on: http://review.gluster.org/14226
Smoke: Gluster Build System <jenkins@build.gluster.com>
NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org>
CentOS-regression: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Jeff Darcy <jdarcy@redhat.com>
|
