<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 Tue, Aug 10, 2021 at 3:23 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>Thanks Ravi, so if I understand correctly latency to all the nodes remains an issue on all file reads.</div><div><br></div></div></blockquote><div><span class="gmail_default" style="font-size:small"><br></span></div><div><span class="gmail_default" style="font-size:small">Hi David, yes, but only for the lookup and opening of the fd. Once the fd is open, all readv calls will go only to the chosen brick.</span></div><div><span class="gmail_default" style="font-size:small">-Ravi</span></div><div><span class="gmail_default" style="font-size:small"></span> </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></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 10 Aug 2021 at 16:49, Ravishankar N <<a href="mailto:ranaraya@redhat.com" target="_blank">ranaraya@redhat.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 dir="ltr"><div style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 10, 2021 at 8:07 AM David Cunningham <<a href="mailto:dcunningham@voisonics.com" target="_blank">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>Hi Gionatan,</div><div><br></div><div>Thanks for that reply. Under normal circumstances there would be nothing that needs to be healed, but how can local-node know this is really the case without checking the other nodes?</div><div><br></div><div>If using local-node tells GlusterFS not to check other nodes for the health of the file at all then this sounds exactly like what we're looking for, although only for a GlusterFS node that is also a client. My understanding is that local-node isn't applicable to a machine that only has the client.</div><div><br></div><div>Does anyone know definitively what is the case here? If not I guess we would need to test it.</div></div></blockquote><div><br></div><div style="font-size:small"><br></div><div style="font-size:small">Knowledge about the file's health is maintained in-memory by AFR xlator on each gluster client (irrespective of where it is mounted). This info is computed during lookup (lookups are always sent to all replica copies) which is issued before any data operation (read, write, etc). See <a href="https://docs.gluster.org/en/latest/Administrator-Guide/Automatic-File-Replication/#read-transactions" target="_blank">https://docs.gluster.org/en/latest/Administrator-Guide/Automatic-File-Replication/#read-transactions</a>.</div><div style="font-size:small"><br></div><div style="font-size:small">Regards,</div><div style="font-size:small">Ravi</div><div style="font-size:small"><br></div><div style="font-size:small"></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>Thank you.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 5 Aug 2021 at 07:28, 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-08-03 19:51 Strahil Nikolov ha scritto:<br>
> The difference between thin and usual arbiter is that the thin arbiter<br>
> takes in action only when it's needed (one of the data bricks is down)<br>
> , so the thin arbiter's lattency won't affect you as long as both data<br>
> bricks are running.<br>
> <br>
> Keep in mind that thin arbiter is less used. For example, I have never<br>
> deployed a thin arbiter.<br>
<br>
Maybe I am horribly wrong, but local-node reads should *not* involve <br>
other nodes in any manner - ie: no checksum or voting is done for read. <br>
AFR hashing should spread different files to different nodes when doing <br>
striping, but for mirroring any node should have a valid copy of the <br>
requested data.<br>
<br>
So when using choose-local all reads which can really be local (ie: the <br>
requested file is available) should not suffer from remote party <br>
latency.<br>
Is that correct?<br>
<br>
Thanks.<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>
</blockquote></div></div>
</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>
</blockquote></div></div>