While testing rolling upgrades from 3.3 to 3.4, I ran into the "Transport Endpoint is not connected" issue on my test client (running 3.3) after rebooting two of my four test GlusterFS 3.4 servers (distributed-replicated-2).
Unmounting and remounting the volume was the only way I could get the error to go away
As the nodes in question were actually up at the time I got the error, and waiting did not help, I checked the client logs and found this:
[2014-03-04 23:19:26.124162] E [dht-common.c:1374:dht_lookup] 0-TEST1-dht: Failed to get hashed subvol for /
[2014-03-04 23:19:26.124434] E [dht-common.c:1374:dht_lookup] 0-TEST1-dht: Failed to get hashed subvol for /
[2014-03-04 23:19:27.626845] I [afr-common.c:3843:afr_local_init] 0-TEST1-replicate-0: no subvolumes up
[2014-03-04 23:19:27.626928] W [fuse-bridge.c:2525:fuse_statfs_cbk] 0-glusterfs-fuse: 77: ERR => -1 (Transport endpoint is not connected)
[2014-03-04 23:19:27.857455] E [common-utils.c:125:gf_resolve_ip6] 0-resolver: getaddrinfo failed (No address associated with hostname)
[2014-03-04 23:19:27.857507] E [name.c:243:af_inet_client_get_remote_sockaddr] 0-TEST1-client-0: DNS resolution failed on host glustertest1
[2014-03-04 23:19:28.047913] E [common-utils.c:125:gf_resolve_ip6] 0-resolver: getaddrinfo failed (No address associated with hostname)
[2014-03-04 23:19:28.047963] E [name.c:243:af_inet_client_get_remote_sockaddr] 0-TEST1-client-1: DNS resolution failed on host glustertest2
These log messages are interesting because although the servers in question (glustertest{1,2,3,4} are not in DNS, they *are* in the /etc/hosts files on all of the hosts in question.
Is it a bug that the client requires that all the GlusterFS servers be in DNS?
Justin Dossey
CTO, PodOmatic
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-users
