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