<html><head/><body><html><head></head><body>0-gfs33-client-2 would be the third brick in the gfs33 volume, so should be glusterfsd rather than glusterd, so not port 24007.<br><br><div class="gmail_quote">krish <kparthas@redhat.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif; margin-top: 0px">Hi Emmanuel,<br /><br />On 03/01/2013 07:55 AM, Emmanuel Dreyfus wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Hi<br /><br />The spurious disconnect I encountered in 3.4 branch still happen in<br />3.4.0alpha, but glusterfs recovers much better now. However, when<br />running huge tar -xzf I still hit operation failures, after which<br />everything is restored to normal state.<br /><br />Here is the client log, in which the issue is hit at 18:06:36<br /><a href="http://ftp.espci.fr/shadow/manu/client.log">http://ftp.espci.fr/shadow/manu/client.log</a><br /><br />The relevant part is below. I understand glusterfs is able to restore<br />its connections and everything works fine, except when it happens on all<br />volumes simultaneously.<br /><br />[2013-02-28 18:06:36.105271] W<br
/>[socket.c:1962:__socket_proto_state_machine] 0-gfs33-client-3: reading<br />from socket failed. Error (No message available), peer<br />(<a href="192.0.2.98:49153">192.0.2.98:49153</a>)<br />[2013-02-28 18:06:36.105340] E [rpc-clnt.c:368:saved_frames_unwind]<br />0-gfs33-client-3: forced unwinding frame type(GlusterFS 3.3)<br />op(LOOKUP(27)) called at 2013-02-28 18:06:36.104358 (xid=0x3728220x)<br />[2013-02-28 18:06:36.105454] W<br />[client-rpc-fops.c:2624:client3_3_lookup_cbk] 0-gfs33-client-3: remote<br />operation failed: Socket is not connected. Path:<br />/manu/netbsd/usr/src/external (6fb65713-062a-464d-a9d4-e97dab3c298b)<br />[2013-02-28 18:06:36.105514] E [rpc-clnt.c:368:saved_frames_unwind]<br />0-gfs33-client-3: forced unwinding frame type(GlusterFS 3.3)<br />op(RELEASE(41)) called at 2013-02-28 18:06:36.104843 (xid=0x3728221x)<br />[2013-02-28 18:06:36.105537] I [client.c:2097:client_rpc_notify]<br />0-gfs33-client-3: disconnected<br />[2013-02-28 18:06:36.105571] E
[afr-common.c:3761:afr_notify]<br />0-gfs33-replicate-1: All subvolumes are down. Going offline until<br />atleast one of them comes back up.[2013-02-28 18:06:36.112037] I<br />[afr-common.c:3882:afr_local_init] 0-gfs33-replicate-1: no subvolumes up<br /></blockquote>I see that 0-gfs33-client-2 xlator is unable to connect to glusterd <br />(that should be) running<br />on hotstuff:24007. The client xlator attempts to reconnect every 3s <br />since last attempt.<br />This is why we see logs about client disconnection repeat.<br /><br />Could you check if glusterd was running on the host "hotstuff", when the <br />client<br />experiences spurious disconnects?<br />To confirm this when you notice the 'spurious' disconnects, try<br /># telnet hotstuff 24007<br /><br />thanks,<br />krish<br /><br /><hr /><br />Gluster-devel mailing list<br />Gluster-devel@nongnu.org<br /><a
href="https://lists.nongnu.org/mailman/listinfo/gluster-devel">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br /></pre></blockquote></div></body></html></body></html>