Thanks Ravi, so if I understand correctly latency to all the nodes remains an issue on all file reads.
On Tue, 10 Aug 2021 at 16:49, Ravishankar N <[email protected]> wrote: > > > On Tue, Aug 10, 2021 at 8:07 AM David Cunningham < > [email protected]> wrote: > >> Hi Gionatan, >> >> 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? >> >> 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. >> >> Does anyone know definitively what is the case here? If not I guess we >> would need to test it. >> > > > 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 > https://docs.gluster.org/en/latest/Administrator-Guide/Automatic-File-Replication/#read-transactions > . > > Regards, > Ravi > > >> Thank you. >> >> On Thu, 5 Aug 2021 at 07:28, Gionatan Danti <[email protected]> wrote: >> >>> Il 2021-08-03 19:51 Strahil Nikolov ha scritto: >>> > 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. >>> > >>> > Keep in mind that thin arbiter is less used. For example, I have never >>> > deployed a thin arbiter. >>> >>> Maybe I am horribly wrong, but local-node reads should *not* involve >>> other nodes in any manner - ie: no checksum or voting is done for read. >>> AFR hashing should spread different files to different nodes when doing >>> striping, but for mirroring any node should have a valid copy of the >>> requested data. >>> >>> So when using choose-local all reads which can really be local (ie: the >>> requested file is available) should not suffer from remote party >>> latency. >>> Is that correct? >>> >>> Thanks. >>> >>> -- >>> Danti Gionatan >>> Supporto Tecnico >>> Assyoma S.r.l. - www.assyoma.it >>> email: [email protected] - [email protected] >>> GPG public key ID: FF5F32A8 >>> >> >> >> -- >> David Cunningham, Voisonics Limited >> http://voisonics.com/ >> USA: +1 213 221 1092 >> New Zealand: +64 (0)28 2558 3782 >> > -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782
________ Community Meeting Calendar: Schedule - Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC Bridge: https://meet.google.com/cpu-eiue-hvk Gluster-users mailing list [email protected] https://lists.gluster.org/mailman/listinfo/gluster-users
