causes gluster to declare the other node dead, and quickly allow access to the common storage content. But in the last 4 days I have been experiencing some weird occurrences. I am using gluster in WAN environment replication, and I am suspecting network connectivity is sometimes timing out. This causes gluster to stall for ~ 1 minute, like the log says: [2012-04-21 18:11:31.758139] C [client-handshake.c:121:rpc_client_ping_timer_expired] 0-comun-vol-client-0: server xxx.xxx.xxx.xxx:24009 has not responded in the last 42 seconds, disconnecting. and also causes big load on the server (100+), freezing all other applications. I have now reconfigured network.ping-timeout to 10. What I would like to achieve is to have minimum "downtime" when bricks are failing. Any other options I can set? --000e0cdfd4d6c268ce04be3515df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello again,<br><br>I am now seeking some advices regarding gluster configuration.<br>I have the following options:<br>Options Reconfigured:<br>nfs.disable: 1<br>network.ping-timeout: 1<br><br>From my tests, I noticed that setting a low network.ping-timeout (1s) causes gluster to declare the other node dead, and quickly allow access to the common storage content. But in the last 4 days I have been experiencing some weird occurrences. I am using gluster in WAN environment replication, and I am suspecting network connectivity is sometimes timing out.<br> This causes gluster to stall for ~ 1 minute, like the log says:<br>[2012-04-21 18:11:31.758139] C [client-handshake.c:121:rpc_client_ping_timer_expired] 0-comun-vol-client-0: server xxx.xxx.xxx.xxx:24009 has not responded in the last 42 seconds, disconnecting.<br> and also causes big load on the server (100+), freezing all other applications.<br><br>I have now reconfigured network.ping-timeout to 10.<br>What I would like to achieve is to have minimum "downtime" when bricks are failing. Any other options I can set?<br> --000e0cdfd4d6c268ce04be3515df--