Anand Avati wrote: > > > /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. This is all. It just happens on boot upon mount. It gives these errors until it finally connects after a few seconds. If I do no operation, it will not work until I do one and get these errors. > > 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. iptables rules are few (around 20) and the average response time is around 100ms (we have an internal DNS server that serves for all internal machines. > 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. Where exactly is the client volume spec file? Can you give me the path? I sure can disable iptables. What I did to have a dirty/ugly workaround for now is to create an init script that performs an `ls` to the mount point. At that point I get the error 'Transport endpoint is not connected', I make the init script wait 10 seconds and when the service that requires the glusterfs partition to be online, it gets it working. My diagnose on this is that until an operation is performed, the connection to the server does not actually get established. After performing any operation on the mount point, it returns 'Transport endpoint is not connected' error and a few seconds later everything is working fine. Weird. > > avati > Thanks, Ioannis
begin:vcard fn:Ioannis Aslanidis n:Aslanidis;Ioannis org:Flumotion Services S.A.;Infrastructure Department adr:Edifici Nord Planta 2;;World Trade Center;Barcelona;Barcelona;08039;Spain email;internet:iaslanidis@xxxxxxxxxxxxx title:System and Network Administrator tel;work:+34935086359 tel;cell:+34627204575 url:http://www.flumotion.com version:2.1 end:vcard
Attachment:
signature.asc
Description: OpenPGP digital signature
