diff options
author | Kaushal M <kaushal@redhat.com> | 2015-07-10 14:50:29 +0530 |
---|---|---|
committer | Krishnan Parthasarathi <kparthas@redhat.com> | 2015-07-11 00:18:09 -0700 |
commit | 93d8af231927d3476f8a966505a0e7fab7181385 (patch) | |
tree | 847106542fa3031da8dab60de0f9f30d284b36e2 /xlators | |
parent | 2992c18c1370ada476223b496e4e970d70cdd359 (diff) | |
download | glusterfs-93d8af231927d3476f8a966505a0e7fab7181385.tar.gz glusterfs-93d8af231927d3476f8a966505a0e7fab7181385.tar.xz glusterfs-93d8af231927d3476f8a966505a0e7fab7181385.zip |
glusterd: Send friend update even for EVENT_RCVD_ACC
In a multi-network cluster, a new peer being probed into the cluster
will not get all the addresses of the peer that initiated the probe in
some cases as it doesn't recieve friend updates from other peers in the
cluster.
This happens when the new peer establishes connection with the other
peers before the other peers connect to the new peer.
Assuming, F is the initiator peer, O is one of the other peers in the
cluster and N is the new peer, the following series of events occur on O
when N establishes the connection first. N is already in the BEFRIENDED
state on O, and the actions happening will refer the BEFRIENDED state
table.
EVENT_RCV_FRIEND_REQ -> results in handle_friend_add_req being called
which injects a LOCAL_ACC
EVENT_RCVC_LOCAL_ACC -> results in send_friend_update being called
which should have sent an update to N, but O
has still not established a connection to N,
so the update isn't sent
EVENT_CONNECTED -> O now connects to N, this results in O sending a
friend_add req to N
EVENT_RCVD_ACC -> friend_add_cbk inject this event, but this event
results in a NOOP when in BEFRIENDED
As a result this O doesn't recieve all the addresses of F. If the
cluster contains any volumes with bricks attached to the missing
addresses of F and O is restarted in this condition, GlusterD will fail
to start as it wouldn't be able to resolve those bricks.
This commit changes the EVENT_RCVD_ACC action for the BEFRIENDED state
from a NOOP to send_friend_update. This makes sure that the new peer
recieves the updates from the other existing peers, irrespective of who
establishes the connection first, thus solving the problem.
Change-Id: Id807bc3032cf4cb13a5ba83819f2d50c96e76e96
BUG: 1241882
Signed-off-by: Kaushal M <kaushal@redhat.com>
Reviewed-on: http://review.gluster.org/11625
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com>
Diffstat (limited to 'xlators')
-rw-r--r-- | xlators/mgmt/glusterd/src/glusterd-sm.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/xlators/mgmt/glusterd/src/glusterd-sm.c b/xlators/mgmt/glusterd/src/glusterd-sm.c index 6acf56fd2d..0455c54964 100644 --- a/xlators/mgmt/glusterd/src/glusterd-sm.c +++ b/xlators/mgmt/glusterd/src/glusterd-sm.c @@ -1020,7 +1020,7 @@ glusterd_sm_t glusterd_state_befriended [] = { {GD_FRIEND_STATE_BEFRIENDED, glusterd_ac_none}, //EVENT_NONE, {GD_FRIEND_STATE_BEFRIENDED, glusterd_ac_none}, //EVENT_PROBE, {GD_FRIEND_STATE_BEFRIENDED, glusterd_ac_none}, //EVENT_INIT_FRIEND_REQ, - {GD_FRIEND_STATE_BEFRIENDED, glusterd_ac_none}, //EVENT_RCVD_ACC + {GD_FRIEND_STATE_BEFRIENDED, glusterd_ac_send_friend_update}, //EVENT_RCVD_ACC {GD_FRIEND_STATE_BEFRIENDED, glusterd_ac_send_friend_update}, //EVENT_RCVD_LOCAL_ACC {GD_FRIEND_STATE_REJECTED, glusterd_ac_none}, //EVENT_RCVD_RJT {GD_FRIEND_STATE_REJECTED, glusterd_ac_none}, //EVENT_RCVD_LOCAL_RJT |