[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20081105/d4fe433e/attachment-0003.html>