<font size=3 color=blue face="Times New Roman">It seems I found out what
goes wrong here - and this was useful learning to me:</font>
<br>
<br><font size=3 color=blue face="Times New Roman">On one of the replica
servers, the client mount did not have an open port to communicate with
the other krfsd process. To illustrate:</font>
<br>
<br><font size=2 face="Courier New">root@serv1:/root&gt; ps -ef | grep
replicated_vol</font>
<br><font size=2 face="Courier New">root &nbsp; &nbsp; 30627 &nbsp; &nbsp;
1 &nbsp;0 Jan29 ? &nbsp; &nbsp; &nbsp; &nbsp;00:17:30 /usr/sbin/glusterfs
--volfile-id=replicated_vol --volfile-server=serv1 /mnt/replicated_vol</font>
<br><font size=2 face="Courier New">root &nbsp; &nbsp; 31132 18322 &nbsp;0
23:04 pts/1 &nbsp; &nbsp;00:00:00 grep _opt_kapsch_cnp_data_memusage</font>
<br><font size=2 face="Courier New">root &nbsp; &nbsp; 31280 &nbsp; &nbsp;
1 &nbsp;0 06:32 ? &nbsp; &nbsp; &nbsp; &nbsp;00:09:10 /usr/sbin/glusterfsd
-s serv1 --volfile-id replicated_vol.serv1.mnt-bricks-replicated_vol-brick
-p /var/lib/glusterd/vols/replicated_vol/run/serv1-mnt-bricks-replicated_vol-brick.pid
-S /var/run/4d70e99b47c1f95cc2eab1715d3a9b67.socket --brick-name /mnt/bricks/replicated_vol/brick
-l /var/log/glusterfs/bricks/mnt-bricks-replicated_vol-bricks.log --xlator-option
*-posix.glusterd-uuid=c7930be6-969f-4f62-b119-c5bbe4df22a3 --brick-port
49172 --xlator-option replicated_vol.listen-port=49172</font>
<br>
<br>
<br><font size=2 face="Courier New">root@serv1:/root&gt; netstat -p | grep
30627</font>
<br><font size=2 face="Courier New">tcp &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp;
&nbsp; &nbsp;0 serv1:715 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; serv1:24007
&nbsp; &nbsp; &nbsp; &nbsp; ESTABLISHED 30627/glusterfs </font><font size=2 color=#c20000 face="Courier New">&lt;=
client&lt;-&gt;local glusterd</font>
<br><font size=2 face="Courier New">tcp &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp;
&nbsp; &nbsp;0 serv1:863 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; serv1:49172
&nbsp; &nbsp; &nbsp; &nbsp; ESTABLISHED 30627/glusterfs </font><font size=2 color=#c20000 face="Courier New">&lt;=
client&lt;-&gt;local brick</font>
<br><font size=2 face="Courier New">root@serv1:/root&gt; </font>
<br>
<br><font size=3 color=blue face="Times New Roman">However, the client
on the other server did have a port open to the mount, and so whatever
one wrote on the other server synced over immediately.</font>
<br>
<br><font size=2 face="Courier New">root@serv0:/root&gt; ps -ef | grep
replicated_vol</font>
<br><font size=2 face="Courier New">root &nbsp; &nbsp; 12761 &nbsp;7556
&nbsp;0 23:05 pts/1 &nbsp; &nbsp;00:00:00 replicated_vol</font>
<br><font size=2 face="Courier New">root &nbsp; &nbsp; 15067 &nbsp; &nbsp;
1 &nbsp;0 06:32 ? &nbsp; &nbsp; &nbsp; &nbsp;00:04:50 /usr/sbin/glusterfsd
-s serv1 --volfile-id replicated_vol.serv1.mnt-bricks-replicated_vol-brick
-p /var/lib/glusterd/vols/replicated_vol/run/serv1-mnt-bricks-replicated_vol-brick.pid
-S /var/run/f642d7dbff0ab7a475a23236f6f50b33.socket --brick-name /mnt/bricks/replicated_vol/brick
-l /var/log/glusterfs/bricks/mnt-bricks-replicated_vol-bricks.log --xlator-option
*-posix.glusterd-uuid=13df1bd2-6dc8-49fa-ade0-5cd95f6b1f19 --brick-port
49209 --xlator-option replicated_vol.listen-port=49209</font>
<br><font size=2 face="Courier New">root &nbsp; &nbsp; 30587 &nbsp; &nbsp;
1 &nbsp;0 Jan30 ? &nbsp; &nbsp; &nbsp; &nbsp;00:12:17 /usr/sbin/glusterfs
--volfile-id=serv --volfile-server=serv0 /mnt/replicated_vol</font>
<br>
<br><font size=2 face="Courier New">root@serv0:/root&gt; netstat -p | grep
30587</font>
<br><font size=2 face="Courier New">tcp &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp;
&nbsp; &nbsp;0 serv0:859 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; serv1:49172
&nbsp; &nbsp; &nbsp; &nbsp; ESTABLISHED 30587/glusterfs </font><font size=2 color=#c20000 face="Courier New">&lt;=
client&lt;-&gt;remote brick</font>
<br><font size=2 face="Courier New">tcp &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp;
&nbsp; &nbsp;0 serv0:746 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; serv0:24007
&nbsp; &nbsp; &nbsp; &nbsp; ESTABLISHED 30587/glusterfs </font><font size=2 color=#c20000 face="Courier New">&lt;=
client&lt;-&gt;glusterd</font>
<br><font size=2 face="Courier New">tcp &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp;
&nbsp; &nbsp;0 serv0:857 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; serv0:49209
&nbsp; &nbsp; &nbsp; &nbsp; ESTABLISHED 30587/glusterfs </font><font size=2 color=#c20000 face="Courier New">&lt;=
client&lt;-&gt;local brick</font>
<br><font size=2 face="Courier New">root@serv0:/root&gt; </font>
<br>
<br><font size=3 color=blue face="Times New Roman">So, the client has no
open tcp link with the mate brick - which is why it cannot write to the
mate brick directly, and instead has to rely on the self-heal daemon instead
to do the job. Of course, I now need to debug why the connection fails,
but at least we are clean on AFR. </font>
<br>
<br><font size=3 color=blue face="Times New Roman">Thanks everyone.</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From: &nbsp; &nbsp; &nbsp;
&nbsp;</font><font size=1 face="sans-serif">A Ghoshal &lt;a.ghoshal@tcs.com&gt;</font>
<br><font size=1 color=#5f5f5f face="sans-serif">To: &nbsp; &nbsp; &nbsp;
&nbsp;</font><font size=1 face="sans-serif">gluster-users@gluster.org</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date: &nbsp; &nbsp; &nbsp;
&nbsp;</font><font size=1 face="sans-serif">02/03/2015 12:00 AM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject: &nbsp; &nbsp;
&nbsp; &nbsp;</font><font size=1 face="sans-serif">[Gluster-users]
A few queries on self-healing and AFR (glusterfs &nbsp; &nbsp; &nbsp; &nbsp;3.4.2)</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by: &nbsp; &nbsp;
&nbsp; &nbsp;</font><font size=1 face="sans-serif">gluster-users-bounces@gluster.org</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3 color=blue face="Times New Roman">Hello,</font><font size=3>
<br>
</font><font size=3 color=blue face="Times New Roman"><br>
I have a replica-2 volume in which I store a large number of files that
are updated frequently (critical log files, etc). My files are generally
stable, but one thing that does worry me from time to time is that files
show up on one of the bricks in the output of gluster v &lt;volname&gt;
heal info. These entries disappear on their own after a while (I am guessing
when cluster.heal-timeout expires and another heal by the self-heal daemon
is triggered). For certain files, this could be a bit of a bother - in
terms of fault tolerance...</font><font size=3> <br>
</font><font size=3 color=blue face="Times New Roman"><br>
I was wondering if there is a way I could force AFR to return write-completion
to the application only _after_ the data is written to both replicas successfully
(kind of, like, atomic writes) - even if it were at the cost of performance.
This way I could ensure that my bricks shall always be in sync. </font><font size=3><br>
</font><font size=3 color=blue face="Times New Roman"><br>
The other thing I could possibly do is reduce my cluster.heal-timeout (it
is 600 currently). Is it a bad idea to set it to something as small as
say, 60 seconds for volumes where redundancy is a prime concern? </font><font size=3><br>
</font><font size=3 color=blue face="Times New Roman"><br>
One question, though - is heal through self-heal daemon accomplished using
separate threads for each replicated volume, or is it a single thread for
every volume? The reason I ask is I have a large number of replicated file-systems
on each volume (17, to be precise) but I do have a reasonably powerful
multicore processor array and large RAM and top indicates the load on the
system resources is quite moderate.</font><font size=3> <br>
</font><font size=3 color=blue face="Times New Roman"><br>
Thanks,</font><font size=3> </font><font size=3 color=blue face="Times New Roman"><br>
Anirban</font>
<p><font size=3>=====-----=====-----=====<br>
Notice: The information contained in this e-mail<br>
message and/or attachments to it may contain <br>
confidential or privileged information. If you are <br>
not the intended recipient, any dissemination, use, <br>
review, distribution, printing or copying of the <br>
information contained in this e-mail message <br>
and/or attachments to it are strictly prohibited. If <br>
you have received this communication in error, <br>
please notify us by reply e-mail or telephone and <br>
immediately and permanently delete the message <br>
and any attachments. Thank you</font><tt><font size=2>_______________________________________________<br>
Gluster-users mailing list<br>
Gluster-users@gluster.org<br>
</font></tt><a href="http://www.gluster.org/mailman/listinfo/gluster-users"><tt><font size=2>http://www.gluster.org/mailman/listinfo/gluster-users</font></tt></a>
<p>