<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><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">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" class="gmail_signature"><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>