<html><body><div style="font-family: garamond,new york,times,serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"A Ghoshal" <a.ghoshal@tcs.com><br><b>To: </b>gluster-users@gluster.org<br><b>Sent: </b>Tuesday, February 3, 2015 12:00:15 AM<br><b>Subject: </b>[Gluster-users] A few queries on self-healing and AFR (glusterfs 3.4.2)<br><div><br></div><span size="3" color="blue" face="Times New Roman" data-mce-style="color: blue; font-family: 'Times New Roman'; font-size: medium;" style="color: blue; font-family: 'Times New Roman'; font-size: medium;">Hello,</span><br><br><span size="3" color="blue" face="Times New Roman" data-mce-style="color: blue; font-family: 'Times New Roman'; font-size: medium;" style="color: blue; font-family: 'Times New Roman'; font-size: medium;">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 <volname> 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...</span></blockquote><div>In 3.4.x, even files that are currently undergoing modification will be listed in heal-info output. So this could be the reason why the file(s) disappear from the output after a while, in which case reducing cluster.heal-timeout might not solve the problem. Since 3.5.1, heal-info _only_ reports those files which are truly undergoing heal.</div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br><br><span size="3" color="blue" face="Times New Roman" data-mce-style="color: blue; font-family: 'Times New Roman'; font-size: medium;" style="color: blue; font-family: 'Times New Roman'; font-size: medium;">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. </span></blockquote><div>AFR has always returned write-completion status to the application only _after_ the data is written to all replicas. The appearance of files under modification in heal-info output might have led you to think the changes have not (yet) been synced to the other replica(s).</div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br><br><span size="3" color="blue" face="Times New Roman" data-mce-style="color: blue; font-family: 'Times New Roman'; font-size: medium;" style="color: blue; font-family: 'Times New Roman'; font-size: medium;">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? </span><br><br><span size="3" color="blue" face="Times New Roman" data-mce-style="color: blue; font-family: 'Times New Roman'; font-size: medium;" style="color: blue; font-family: 'Times New Roman'; font-size: medium;">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.</span></blockquote><div>There is an infra piece called syncop in gluster using which multiple heal jobs are handled by handful of threads. The maximum it can scale up to is 16 depending on the load. It is safe to assume that there will be one healer thread per replica set. But if the load is not too high, just 1 thread may do all the healing.</div><div><br></div><div>-Krutika</div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><span size="3" color="blue" face="Times New Roman" data-mce-style="color: blue; font-family: 'Times New Roman'; font-size: medium;" style="color: blue; font-family: 'Times New Roman'; font-size: medium;">Thanks,</span><br><span size="3" color="blue" face="Times New Roman" data-mce-style="color: blue; font-family: 'Times New Roman'; font-size: medium;" style="color: blue; font-family: 'Times New Roman'; font-size: medium;">Anirban</span><p>=====-----=====-----=====<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</p><br>_______________________________________________<br>Gluster-users mailing list<br>Gluster-users@gluster.org<br>http://www.gluster.org/mailman/listinfo/gluster-users</blockquote><div><br></div></div></body></html>