Gluster users - Apr 2020 - Lightweight read

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
>
>
-- 
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/20200425/96c7a322/attachment.html>

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