I think you mean cluster.choose-local which is enabled by default. Yet, Gluster
will check if the local copy is healthy.
Best Regards,
Strahil Nikolov
В сряда, 28 юли 2021 г., 10:20:55 ч. Гринуич+3, Yaniv Kaul
написа:
On Wed, Jul 28, 2021 at 5:50 AM David Cunningham
wrote:
> Hi
Il 2021-07-28 13:11 Strahil Nikolov ha scritto:
I think you mean cluster.choose-local which is enabled by default.
Yet, Gluster will check if the local copy is healthy.
Ah, ok, from reading here [1] I was under the impression that
cluster.choose-local was somewhat deprecated.
Good to know
First readable child... Isn't this the first brick in the subvolume ?
David, you just want to skip the lookups and you need gluster to just serve the
file, right ?
I think that you can play a little bit with md-cache. There is a nice article
(requires RH dev or real subscription):
Il 2021-07-28 09:20 Yaniv Kaul ha scritto:
In real life, the 'best' node is the one with the highest overall free
resources, across CPU, network and disk IO. So it could change and it
might change all the time.
Network, disk saturation might be common, disk performing garbage
collection, CPU
On Wed, Jul 28, 2021 at 5:50 AM David Cunningham
wrote:
> Hi Yaniv,
>
> It may be my lack of knowledge, but I can't see how the fastest response
> time could differ from file to file. If that's true then it would be enough
> to only periodically test which node is fastest for this client, not
