Hi Strahil,
Thanks for the tip about choose-local. Am I right in thinking that it only
applies to reads on a GlusterFS server node itself, and not on GlusterFS
clients?
If so then perhaps the effect could be expanded to clients by using NFS to
access the GlusterFS server instead of the GlusterFS native client.
BTW, under normal circumstances when the client checks all bricks, does
that include checking an arbiter? Or are arbiters not checked?
On Sat, 25 Apr 2020 at 19:41, Strahil Nikolov <hunter86_bg at yahoo.com>
wrote:
> On April 25, 2020 9:00:30 AM GMT+03:00, David Cunningham <
> dcunningham at voisonics.com> wrote:
> >Hi Ravi,
> >
> >Thank you for the reply, and yes they are replica volumes. Is it
> >possible
> >to improve performance by the client only accessing its configured
> >server
> >for reads, or would the difference be negligible?
> >
> >
> >On Fri, 24 Apr 2020 at 18:46, Ravishankar N <ravishankar at
redhat.com>
> >wrote:
> >
> >>
> >> On 24/04/20 11:42 am, David Cunningham wrote:
> >>
> >> Hello,
> >>
> >> My understanding is that GlusterFS checks with all nodes when
> >performing a
> >> read. Is it possible to just get the data from the node directly
> >being
> >> accessed (in our case using the GlusterFS client), without
consulting
> >with
> >> the other nodes?
> >>
> >> Our application requires the GFS file to be available, but
it's
> >actually
> >> not critical if we end up with an old version of the file in the
case
> >of a
> >> server down or net-split etc. Significantly improved read
performance
> >would
> >> be desirable instead.
> >>
> >> I assume you are talking about replica volumes, in which case the
> >read
> >> does happen from only one of the replica bricks. The client only
> >sends
> >> lookups to all the bricks to figure out which are the good copies.
> >Post
> >> that, the reads themselves are served from only one of the good
> >copies.
> >>
> >> -Ravi
> >>
> >>
> >> Thanks in advance for any help.
> >>
> >> --
> >> 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://bluejeans.com/441850968
> >>
> >> Gluster-users mailing
> >listGluster-users at gluster.orghttps://
> lists.gluster.org/mailman/listinfo/gluster-users
> >>
> >>
>
> Hey David,
> There is a cluster.choose-local (I think it was 'cluster , but I
> could be wrong) option that allows a node to read locally - in my case
> I'm using it cause my network is slower than my NVMe so reads over the
> network are slow.
>
> Best Regards,
> Strahil Nikolov
>
--
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gluster.org/pipermail/gluster-users/attachments/20200430/3193c251/attachment.html>