<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 29, 2021 at 3:16 PM David Cunningham <<a href="mailto:dcunningham@voisonics.com">dcunningham@voisonics.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello,</div><div><br></div><div>Thanks for all the replies. I'll try to address each point:</div><div><br></div><div>1. "First readable child... Isn't this the first brick in the subvolume"</div><div>Does that mean the first brick in the list returned by "gluster volume status"?</div><div><br></div><div>2. "I think that you can play a little bit with md-cache"</div><div>Unfortunately I don't have access to the RH article. We would be happy to skip the lookups when reading a file, as long as some data is returned and the file read doesn't block or fail. Do you think that md-cache can accomplish this? If so we might invest more in researching it.</div><div><br></div><div>3. "In real life, the 'best' node is the one with the highest overall free resources, across CPU, network and disk IO."</div><div>My question relates to a slightly different real life, where some of the nodes are within a very short latency (eg 0.15ms) and some others are further away (eg 15ms). What we want to avoid is the 15ms delay to check the nodes further away. The CPU, disk IO, etc load on each server is going to be insignificant compared to the difference in the latency between nodes.<br></div><div><br></div><div>4. "Our latency check is indeed not per file, AFAIK."</div><div>If GlusterFS checks the health of the file on each read then I guess the latency to all nodes will be a factor on each read. This is what we're looking for a way to avoid.<br></div><div><br></div><div>5. "I think you mean cluster.choose-local which is enabled by default. Yet, Gluster will check if the local copy is healthy."</div><div>What is the local copy exactly? I'm talking from the point of view of a machine which is running the GlusterFS FUSE client, and is not a GlusterFS node.</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Local copy means the fuse client is mounted on the same node as that of the brick and the file in question happens to reside on that brick.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">First readable child simply means the first healthy brick (i.e no pending heals) as you iterate through a 'for loop' of all bricks beginning with brick-0. So if you set the read-hash-mode to 0, and if all bricks were healthy, the reads will always be served from brick-0.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">> 4 = brick having the least network ping latency.</div><div class="gmail_default" style="font-size:small">Like Yaniv said, the latency check is *not* on a per file. When the client attempts to connect to the bricks at the time of mount, the ping time of all bricks are captured and the one with the lowest value is used thereafter.</div><br></div><div><div class="gmail_default" style="font-size:small">If you have already identified that a particular brick has the lowest latency w.r.t communicating with the client, you can also use that brick using the `read-subvolume-index` option. But bear in mind all these policies are global and will affect all clients. Also, AFR based replication is synchronous and not an eventual consistency model. So your original requirement of older reads won't work - i.e. read will never be served from a brick that needs heal even if it is the fastest.</div><br></div><div><div class="gmail_default" style="font-size:small">You can look at afr_read_subvol_select_by_policy() in the code if you want to get a glimpse of the internals.</div><br></div><div><div class="gmail_default" style="font-size:small">Hope that helps,</div><div class="gmail_default" style="font-size:small">Ravi</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Thanks again for the input.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 28 Jul 2021 at 23:36, Gionatan Danti <<a href="mailto:g.danti@assyoma.it" target="_blank">g.danti@assyoma.it</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Il 2021-07-28 13:11 Strahil Nikolov ha scritto:<br>
> I think you mean cluster.choose-local which is enabled by default.<br>
> Yet, Gluster will check if the local copy is healthy.<br>
<br>
Ah, ok, from reading here [1] I was under the impression that <br>
cluster.choose-local was somewhat deprecated.<br>
Good to know that it is here to stay!<br>
Regards.<br>
<br>
[1] <br>
<a href="https://lists.gluster.org/pipermail/gluster-users/2015-June/022288.html" rel="noreferrer" target="_blank">https://lists.gluster.org/pipermail/gluster-users/2015-June/022288.html</a><br>
<br>
<br>
-- <br>
Danti Gionatan<br>
Supporto Tecnico<br>
Assyoma S.r.l. - <a href="http://www.assyoma.it" rel="noreferrer" target="_blank">www.assyoma.it</a><br>
email: <a href="mailto:g.danti@assyoma.it" target="_blank">g.danti@assyoma.it</a> - <a href="mailto:info@assyoma.it" target="_blank">info@assyoma.it</a><br>
GPG public key ID: FF5F32A8<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>David Cunningham, Voisonics Limited<br><a href="http://voisonics.com/" target="_blank">http://voisonics.com/</a><br>USA: +1 213 221 1092<br>New Zealand: +64 (0)28 2558 3782</div></div></div></div></div></div></div></div></div></div></div>
________<br>
<br>
<br>
<br>
Community Meeting Calendar:<br>
<br>
Schedule -<br>
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC<br>
Bridge: <a href="https://meet.google.com/cpu-eiue-hvk" rel="noreferrer" target="_blank">https://meet.google.com/cpu-eiue-hvk</a><br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-users</a><br>
</blockquote></div></div>