Re: Glusterfs not mounting correctly during boot under RHEL 5.2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





/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


[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux