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 <g.danti@xxxxxxxxxx> 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: g.danti@xxxxxxxxxx - info@xxxxxxxxxx
GPG public key ID: FF5F32A8
--
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782
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 Gluster-users@xxxxxxxxxxx https://lists.gluster.org/mailman/listinfo/gluster-users
