Re: [Gluster-devel] Glusterfs not mounting correctly during boot under RHEL 5.2

[Anand Avati]

/var/log/glusterfs/glusterfs.log

2008-11-05 13:03:14 E [client-protocol.c:4405:client_lookup_cbk]

filedata: no proper reply from server, returning ENOTCONN

2008-11-05 13:03:14 E [fuse-bridge.c:459:fuse_entry_cbk] glusterfs-fuse:
2: (34) / => -1 (107)
2008-11-05 13:03:14 E [client-protocol.c:4405:client_lookup_cbk]

filedata: no proper reply from server, returning ENOTCONN

2008-11-05 13:03:14 E [fuse-bridge.c:459:fuse_entry_cbk] glusterfs-fuse:
2: (34) / => -1 (107)
2008-11-05 13:03:15 E [client-protocol.c:4405:client_lookup_cbk]

filedata: no proper reply from server, returning ENOTCONN

2008-11-05 13:03:15 E [fuse-bridge.c:459:fuse_entry_cbk] glusterfs-fuse:
3: (34) / => -1 (107)
2008-11-05 13:03:15 E [client-protocol.c:4405:client_lookup_cbk]

filedata: no proper reply from server, returning ENOTCONN

2008-11-05 13:03:15 E [fuse-bridge.c:459:fuse_entry_cbk] glusterfs-fuse:
3: (34) / => -1 (107)
2008-11-05 13:03:16 E [client-protocol.c:4405:client_lookup_cbk]

filedata: no proper reply from server, returning ENOTCONN

2008-11-05 13:03:16 E [fuse-bridge.c:459:fuse_entry_cbk] glusterfs-fuse:
4: (34) / => -1 (107)
2008-11-05 13:03:16 E [client-protocol.c:4405:client_lookup_cbk]

filedata: no proper reply from server, returning ENOTCONN

2008-11-05 13:03:16 E [fuse-bridge.c:459:fuse_entry_cbk] glusterfs-fuse:
4: (34) / => -1 (107)
2008-11-05 13:03:17 E [client-protocol.c:4405:client_lookup_cbk]

filedata: no proper reply from server, returning ENOTCONN

2008-11-05 13:03:17 E [fuse-bridge.c:459:fuse_entry_cbk] glusterfs-fuse:
5: (34) / => -1 (107)
2008-11-05 13:03:17 E [client-protocol.c:4405:client_lookup_cbk]

filedata: no proper reply from server, returning ENOTCONN

2008-11-05 13:03:17 E [fuse-bridge.c:459:fuse_entry_cbk] glusterfs-fuse:
5: (34) / => -1 (107)

Is this the complete glusterfs client log file? Is this all? There must be other logs related to connection state if a disconnection happened.

If a disconnection has not happened, then it means that on this particular system some other network connection parameter is slow -- either DNS resolution is slow or tcp connection estabilishment (due to expensive iptables rules?) is slow. To rule these out, can you ensure you have mentioned IP addresses in the client volume spec file (instead of hostnames) and disabling iptables from init.

avati