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 >
________ 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
