The bug is not reproducible with glusterfs--mainline--3.0--patch-903. Can you check whether it is possible to reproduce the issue?
regards,
Hi,
I've tried setting up the HA translator using glusterfs-2.0.0rc1 and fuse-2.7.4glfs11. I have a 2 clients connecting to the 2 glusterfs-servers (lb1 and lb2) which run server-side AFR between themselves. To test if the HA works, I shutdown the lb1. I could see both the clients switching to lb2 in the log (fuse-bridge: inode num of /globalshare changed 54394886 -> 30605318) so it works fine. However when I restarted lb1 and try to shutdown lb2, 1 of the clients report "Transport endpoint is not connected" and the logs are as below. Can someone advise if HA translator is currently stable?
1: #############################################
2: ## GlusterFS Client Volume Specification ##
3: #############################################
4:
5: # the exported volume to mount # required!
6: volume cluster
7: type protocol/client
8: option transport-type tcp/client
10: option remote-host lb1.world.net
11: option remote-subvolume gfs # exported volume
12: option transport-timeout 5 # value in seconds, should be relatively low
13: end-volume
14:
15: # the exported volume to mount # required!
16: volume cluster2
17: type protocol/client
18: option transport-type tcp/client
20: option remote-host lb2.world.net
21: option remote-subvolume gfs # exported volume
22: option transport-timeout 5 # value in seconds, should be relatively low
23: end-volume
24:
25: volume glusterfs-ha
26: type cluster/ha
27: subvolumes cluster cluster2
28: end-volume
29:
30:
31:
+-----
2009-02-05 18:08:01 E [socket.c:708:socket_connect_finish] cluster2: connection failed (Connection refused)
2009-02-05 18:08:06 W [fuse-bridge.c:304:need_fresh_lookup] fuse-bridge: inode num of /globalshare changed 54394886 -> 30605318
2009-02-05 18:09:25 E [socket.c:104:__socket_rwv] cluster: readv failed (Connection reset by peer)
2009-02-05 18:09:25 E [socket.c:566:socket_proto_state_machine] cluster: socket read failed (Connection reset by peer) in state 1 (192.168.89.151:6996)
2009-02-05 18:09:25 E [saved-frames.c:148:saved_frames_unwind] cluster: forced unwinding frame type(1) op(READ)
Regards,
melvin
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/gluster-devel
--
Raghavendra G
