Thanks Ravi. That was my understanding - that the opening of the file is checked for health with all nodes, and then the file is actually read from one node. I think it's clear that checking with all nodes when opening the file for a read can't be avoided at the moment.
On Tue, 10 Aug 2021 at 22:32, Ravishankar N <[email protected]> wrote: > > > On Tue, Aug 10, 2021 at 3:23 PM David Cunningham < > [email protected]> wrote: > >> Thanks Ravi, so if I understand correctly latency to all the nodes >> remains an issue on all file reads. >> >> > 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. > -Ravi > > >> >> 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 >> > -- 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
