md-caching is not a panacea for your case, but it could help to some extend.<div id="yMail_cursorElementTracker_1628012869828"><br></div><div id="yMail_cursorElementTracker_1628012869960">The difference between thin and usual arbiter is that the thin arbiter takes in action only when it's needed (one of the data bricks is down) , so the thin arbiter's lattency won't affect you as long as both data bricks are running.</div><div id="yMail_cursorElementTracker_1628012986552"><br></div><div id="yMail_cursorElementTracker_1628012986761">Keep in mind that thin arbiter is less used. For example, I have never deployed a thin arbiter.</div><div id="yMail_cursorElementTracker_1628013055591"><br></div><div id="yMail_cursorElementTracker_1628013055835">Best Regards,</div><div id="yMail_cursorElementTracker_1628013060310">Strahil Nikolov<br> <br> <blockquote style="margin: 0 0 20px 0;"> <div style="font-family:Roboto, sans-serif; color:#6D00F6;"> <div>On Tue, Aug 3, 2021 at 7:40, David Cunningham</div><div><dcunningham@voisonics.com> wrote:</div> </div> <div style="padding: 10px 0 0 20px; margin: 10px 0 0 0; border-left: 1px solid #6D00F6;"> <div id="yiv7756796667"><div><div dir="ltr"><div>Hi Strahil,</div><div><br clear="none"></div><div>I registered and read the article, thank you. It looks like it would help the speed of directory listing and related operations, but I don't see anything to suggest that the other nodes won't be checked on file reads. Am I missing something?</div><div><br clear="none"></div><div>We would probably use something like 2 nodes nearby and 1 remote. I understand that the thin arbiter keeps a track of which nodes are online, but can't see how that will help with file reads and nodes being checked for consistency. Are you able to explain please?</div><div><br clear="none"></div><div>Thanks.</div><div><br clear="none"></div><div><br clear="none"></div></div><br clear="none"><div class="yiv7756796667yqt8919703994" id="yiv7756796667yqt39967"><div class="yiv7756796667gmail_quote"><div class="yiv7756796667gmail_attr" dir="ltr">On Mon, 2 Aug 2021 at 17:45, Strahil Nikolov <<a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:hunter86_bg@yahoo.com" target="_blank" href="mailto:hunter86_bg@yahoo.com">hunter86_bg@yahoo.com</a>> wrote:<br clear="none"></div><blockquote class="yiv7756796667gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;">Hi David,<div id="yiv7756796667gmail-m_-6468508227183660670yMail_cursorElementTracker_1627882889350"><br clear="none"></div><div id="yiv7756796667gmail-m_-6468508227183660670yMail_cursorElementTracker_1627882889523">Can you register at <a rel="nofollow noopener noreferrer" shape="rect" target="_blank" href="http://developers.redhat.com">developers.redhat.com</a> and check the article about the md-cache. I think that for most cases the caching should be sufficient in order to not lookup the remote node.</div><div id="yiv7756796667gmail-m_-6468508227183660670yMail_cursorElementTracker_1627882993204"><br clear="none"></div><div id="yiv7756796667gmail-m_-6468508227183660670yMail_cursorElementTracker_1627882993537">By the way, are at least 2 of nodes nearby (lower lattency)? If only 1 node is 'remote' , then you can give a try to gluster's thin arbiter (for the 'remote' node).</div><div id="yiv7756796667gmail-m_-6468508227183660670yMail_cursorElementTracker_1627883055815"><br clear="none"></div><div id="yiv7756796667gmail-m_-6468508227183660670yMail_cursorElementTracker_1627883056029"><br clear="none"></div><div id="yiv7756796667gmail-m_-6468508227183660670yMail_cursorElementTracker_1627883056237">Best Regards,</div><div id="yiv7756796667gmail-m_-6468508227183660670yMail_cursorElementTracker_1627883059669">Strahil Nikolov</div><div id="yiv7756796667gmail-m_-6468508227183660670yMail_cursorElementTracker_1627883022441"> <br clear="none"> <blockquote style="margin:0px 0px 20px;"> <div style="font-family:Roboto, sans-serif;color:rgb(109,0,246);"> <div>On Mon, Aug 2, 2021 at 5:02, David Cunningham</div><div><<a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:dcunningham@voisonics.com" target="_blank" href="mailto:dcunningham@voisonics.com">dcunningham@voisonics.com</a>> wrote:</div> </div> <div style="padding:10px 0px 0px 20px;margin:10px 0px 0px;border-left:1px solid rgb(109,0,246);"> <div id="yiv7756796667gmail-m_-6468508227183660670yiv0586221507"><div><div dir="ltr"><div>Hi Ravi and Strahil,</div><div><br clear="none"></div><div>Thanks again for your responses. Having one brick be the one to read (but with failover if that node goes completely offline) would be great if we could do it per client, but won't work if all clients have to use the same setting.</div><div><br clear="none"></div><div>I'm not sure about gNFS, but normal NFS is something we've thought about as an option. I'm not sure if it will help though, because if the client NFS mounts the server which has the brick, then when it does a read presumably the brick will be checked for consistency with the other bricks and latency will be a problem again. If my understanding is correct even with choose-local enabled the other bricks will still be checked so the problem is not solved.</div><div><br clear="none"></div><div>I confess that AFR vs eventual consistency is beyond my understanding of replication. In the world of SQL there is Galera cluster, and it will write to all nodes but for reads only checks the node the client is actually connected to. That's the sort of functionality we'd find really helpful for our use-case.</div><div><br clear="none"></div></div><br clear="none"><div id="yiv7756796667gmail-m_-6468508227183660670yiv0586221507yqt77777"><div><div dir="ltr">On Fri, 30 Jul 2021 at 19:21, Strahil Nikolov <<a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:hunter86_bg@yahoo.com" target="_blank" href="mailto:hunter86_bg@yahoo.com">hunter86_bg@yahoo.com</a>> wrote:<br clear="none"></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;"><div id="yiv7756796667gmail-m_-6468508227183660670yiv0586221507gmail-m_2582372744795486192yMail_cursorElementTracker_1627629268959">Hi David,</div><div id="yiv7756796667gmail-m_-6468508227183660670yiv0586221507gmail-m_2582372744795486192yMail_cursorElementTracker_1627629581126"><br clear="none"></div><div id="yiv7756796667gmail-m_-6468508227183660670yiv0586221507gmail-m_2582372744795486192yMail_cursorElementTracker_1627629582088">md-cache will just save some lookup actions across the bricks, but it won't save you from all cases.</div><div id="yiv7756796667gmail-m_-6468508227183660670yiv0586221507gmail-m_2582372744795486192yMail_cursorElementTracker_1627629371714"><br clear="none"></div><div id="yiv7756796667gmail-m_-6468508227183660670yiv0586221507gmail-m_2582372744795486192yMail_cursorElementTracker_1627629371977">Using gNFS + cluster.choose-local is worth exploring, but as gNFS is deprecated I never checked if it will be affected by the lattency of the last brick.</div><div id="yiv7756796667gmail-m_-6468508227183660670yiv0586221507gmail-m_2582372744795486192yMail_cursorElementTracker_1627629466021"><br clear="none"></div><div id="yiv7756796667gmail-m_-6468508227183660670yiv0586221507gmail-m_2582372744795486192yMail_cursorElementTracker_1627629466688">What Ravi proposed looks promising, but it has some drawbacks - for example a brick dies and FUSE clienta have to be adjusted to read from another brick.</div><div id="yiv7756796667gmail-m_-6468508227183660670yiv0586221507gmail-m_2582372744795486192yMail_cursorElementTracker_1627629518409"><br clear="none"></div><div id="yiv7756796667gmail-m_-6468508227183660670yiv0586221507gmail-m_2582372744795486192yMail_cursorElementTracker_1627629518643">Ravi, I think that this topic was already discussed once.</div><div id="yiv7756796667gmail-m_-6468508227183660670yiv0586221507gmail-m_2582372744795486192yMail_cursorElementTracker_1627629567681"><br clear="none"></div><div id="yiv7756796667gmail-m_-6468508227183660670yiv0586221507gmail-m_2582372744795486192yMail_cursorElementTracker_1627629567899">Best Regards,</div><div id="yiv7756796667gmail-m_-6468508227183660670yiv0586221507gmail-m_2582372744795486192yMail_cursorElementTracker_1627629571551">Strahil Nikolov</div> <br clear="none"> <blockquote style="margin:0px 0px 20px;"> <div style="font-family:Roboto, sans-serif;color:rgb(109,0,246);"> <div>On Fri, Jul 30, 2021 at 8:49, Ravishankar N</div><div><<a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:ranaraya@redhat.com" target="_blank" href="mailto:ranaraya@redhat.com">ranaraya@redhat.com</a>> wrote:</div> </div> <div style="padding:10px 0px 0px 20px;margin:10px 0px 0px;border-left:1px solid rgb(109,0,246);"> ________<br clear="none"><br clear="none"><br clear="none"><br clear="none">Community Meeting Calendar:<br clear="none"><br clear="none">Schedule -<br clear="none">Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC<br clear="none">Bridge: <a rel="nofollow noopener noreferrer" shape="rect" target="_blank" href="https://meet.google.com/cpu-eiue-hvk">https://meet.google.com/cpu-eiue-hvk</a><br clear="none">Gluster-users mailing list<br clear="none"><a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:Gluster-users@gluster.org" target="_blank" href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br clear="none"><a rel="nofollow noopener noreferrer" shape="rect" target="_blank" href="https://lists.gluster.org/mailman/listinfo/gluster-users">https://lists.gluster.org/mailman/listinfo/gluster-users</a><div id="yiv7756796667gmail-m_-6468508227183660670yiv0586221507gmail-m_2582372744795486192yqtfd56759"><br clear="none"></div> </div> </blockquote></blockquote></div></div><br clear="all"><br clear="none">-- <br clear="none"><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 clear="none"><a rel="nofollow noopener noreferrer" shape="rect" target="_blank" href="http://voisonics.com/">http://voisonics.com/</a><br clear="none">USA: +1 213 221 1092<br clear="none">New Zealand: +64 (0)28 2558 3782</div></div></div></div></div></div></div></div></div></div></div>
</div></div> </div> </blockquote></div></blockquote></div></div><br clear="all"><br clear="none">-- <br clear="none"><div class="yiv7756796667gmail_signature" 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 clear="none"><a rel="nofollow noopener noreferrer" shape="rect" target="_blank" href="http://voisonics.com/">http://voisonics.com/</a><br clear="none">USA: +1 213 221 1092<br clear="none">New Zealand: +64 (0)28 2558 3782</div></div></div></div></div></div></div></div></div></div></div>
</div></div> </div> </blockquote></div>