Bug 987980

Description of problem: After remove-brick commit from a machine having multiple bricks, the geo-rep in that machine starts using xsync for the other running brick in that machine, because it fails to get the connection to the removed brick, 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
[2013-07-24 18:45:40.343144] I [master(/bricks/s3):461:volinfo_query] _GMaster: new master is 00261f58-a7d5-4c9f-a6a7
-af41b70d92a3
[2013-07-24 18:45:40.343264] I [master(/bricks/s3):465:volinfo_query] _GMaster: primary master with volume id 00261f5
8-a7d5-4c9f-a6a7-af41b70d92a3 ...
[2013-07-24 18:45:50.191620] I [master(/bricks/s6):780:fallback_xsync] _GMaster: falling back to xsync mode
[2013-07-24 18:45:50.194266] I [syncdutils(/bricks/s6):158:finalize] <top>: exiting.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

If you check, it is crawling on two bricks, one is /bricks/s3 and /brick/s6 , /brick/s6 was removed, it failed on that and said falling back to xsync. 


Version-Release number of selected component (if applicable):3.4.0.12rhs.beta6-1.el6rhs.x86_64


How reproducible: Didn't try to reproduce again.


Steps to Reproduce:
1.Create and start geo-rep relationship between master(vol config as given in additional info) and slave.
2.Create some data on the master and let it sync.
3.remove-brick (to have master volume as in the additional info in the second config) 
4.Check the geo-rep log-file from the machine where the bricks were removed. 

Actual results:geo-rep change_detector falls back to xsync


Expected results:It shouldn't falls back to xsync when everything is working fine. 


Additional info:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
volume info before remove-brick 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Volume Name: mastervol
Type: Distributed-Replicate
Volume ID: 00261f58-a7d5-4c9f-a6a7-af41b70d92a3
Status: Started
Number of Bricks: 2 x 2 = 4
Transport-type: tcp
Bricks:
Brick1: machine1:/bricks/s1
Brick2: machine2:/bricks/s2
Brick3: machine3:/bricks/s3
Brick4: machine4:/bricks/s4
Brick5: machine2:/bricks/s5
Brick6: machine3:/bricks/s6

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
volume info after the remove-brick
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Volume Name: mastervol
Type: Distributed-Replicate
Volume ID: 00261f58-a7d5-4c9f-a6a7-af41b70d92a3
Status: Started
Number of Bricks: 2 x 2 = 4
Transport-type: tcp
Bricks:
Brick1: machine1:/bricks/s1
Brick2: machine2:/bricks/s2
Brick3: machine3:/bricks/s3
Brick4: machine4:/bricks/s4
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>