Re: [Gluster-devel] Regarding positioning of nl-cache in gluster client stack

[Poornima Gurusiddaiah]

The only requirement on positioning of nl-cache is its good to load it below 
md-cache. 
It should be ok to load it between shard and DHT. 

Regards, 
Poornima 
- Original Message -

> From: "Pranith Kumar Karampuri" 
> To: "Krutika Dhananjay" 
> Cc: "Poornima Gurusiddaiah" , "Gluster Devel"
> 
> Sent: Monday, July 17, 2017 11:34:52 AM
> Subject: Re: Regarding positioning of nl-cache in gluster client stack

> On Mon, Jul 17, 2017 at 11:31 AM, Krutika Dhananjay < kdhan...@redhat.com >
> wrote:

> > Hi Poornima and Pranith,
> 

> > I see that currently glusterd loads nl-cache between stat-prefetch and
> > open-behind on the client stack. Were there any specific considerations for
> > selecting this position for nl-cache?
> 

> > I was interested to see the performance impact of loading this translator
> > between shard and DHT in the VM store use case stack in terms of reducing
> > the number of lookups shard would have to do to figure out if a shard is
> > already created or not, since shard does its own management of .shard and
> > the files under it.
> 

> > So with this background, do you see any issues with loading nl-cache above
> > DHT in the client stack?
> 

> Nothing I can think of at the moment.

> > -Krutika
> 

> --
> Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Regarding positioning of nl-cache in gluster client stack

[Pranith Kumar Karampuri]

On Mon, Jul 17, 2017 at 11:31 AM, Krutika Dhananjay 
wrote:

> Hi Poornima and Pranith,
>
> I see that currently glusterd loads nl-cache between stat-prefetch and
> open-behind on the client stack. Were there any specific considerations for
> selecting this position for nl-cache?
>
> I was interested to see the performance impact of loading this translator
> between shard and DHT in the VM store use case stack in terms of reducing
> the number of lookups shard would have to do to figure out if a shard is
> already created or not, since shard does its own management of .shard and
> the files under it.
>
> So with this background, do you see any issues with loading nl-cache above
> DHT in the client stack?
>

Nothing I can think of at the moment.


>
> -Krutika
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Regarding positioning of nl-cache in gluster client stack

[Krutika Dhananjay]

Hi Poornima and Pranith,

I see that currently glusterd loads nl-cache between stat-prefetch and
open-behind on the client stack. Were there any specific considerations for
selecting this position for nl-cache?

I was interested to see the performance impact of loading this translator
between shard and DHT in the VM store use case stack in terms of reducing
the number of lookups shard would have to do to figure out if a shard is
already created or not, since shard does its own management of .shard and
the files under it.

So with this background, do you see any issues with loading nl-cache above
DHT in the client stack?

-Krutika
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel