Re: About spread count, lookup and layout

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




----- Original Message -----
> From: "Tahereh Fattahi" <t28.fattahi@xxxxxxxxx>
> To: "Raghavendra Gowdappa" <rgowdapp@xxxxxxxxxx>
> Cc: "Gluster Devel" <gluster-devel@xxxxxxxxxxx>
> Sent: Sunday, April 30, 2017 10:04:25 AM
> Subject: Re:  About spread count, lookup and layout
> 
> Thanks a lot
> I read in document that when we want to create a file, first we should be
> sure that this file does not exist in the directory. So first look at the
> hashed subvolume and if it does not exist then broad cast this lookup to
> other subvolume (when lookup optimize is off) to ensure that this file was
> not created before.

lookup-everywhere was done to handle cases where layout might be wrong, not to handle racing creates.

> I had thought that lookup everywhere is for searching file not for layout.

lookup everywhere searches for file.

> I want to reduce the lookup for file (not layout) when lookup optimize is
> off and compare it when lookup optimize is on. (of course lookup optimize
> on is better , I want do this)

For the cases where file is not present (negative-lookup scenario), lookup optimize will always result in smaller number of lookups.

> 
> On Sun, Apr 30, 2017 at 8:12 AM, Raghavendra Gowdappa <rgowdapp@xxxxxxxxxx>
> wrote:
> 
> >
> >
> > ----- Original Message -----
> > > From: "Tahereh Fattahi" <t28.fattahi@xxxxxxxxx>
> > > To: "Gluster Devel" <gluster-devel@xxxxxxxxxxx>
> > > Sent: Sunday, April 30, 2017 8:03:15 AM
> > > Subject:  About spread count, lookup and layout
> > >
> > > Hi
> > > I have some question about spread count:
> > >
> > > 1. When I set spread count less than subvolume count, I see the hash is
> > > assigned to one directory layout for some subvolumes are zero (that is
> > ok) ,
> > > but I expect these subvolumes should not bee looked up in case
> > > lookup_everywhere for creating a file. Unfortunately I see these lookups
> > in
> > > server profile.
> > > Am I correct?
> >
> > Yes. lookup-everywhere is a fall back mechanism for the scenarios where
> > layout can't be trusted (like in the window b/w fix layout after add/remove
> > brick etc and healing of the immediate children of directory as per the new
> > layout). Since layout itself can't be trusted, it doesn't matter whether it
> > has zero ranges or not. A better way of solving this problem (than
> > identifying 0 ranges etc) is lookup-optimize, which identifies scenarios
> > (predominantly add/remove brick) and decides whether to use
> > lookup-everywhere before saying that a file/directory is not present.
> >
> > > is there any way for this case to reduce the amount of lookups that is
> > send
> > > to the servers? (lookup optimize is off and I want this)
> >
> > Is there any reason why you want lookup-optimize to be off?
> >
> > >
> > > 2. I see the option for changing the spread count and fixing the layout
> > in
> > > dht xlaor (dht_setxattr), but when I tried to set this attribute and
> > change
> > > the layout I dont see any change!! while there is no error and crash (I
> > call
> > > setfattr in client side because I dont see dht xlator in server graph)
> >
> > Probably there might be bugs in that codepath. Can you please file a bug?
> >
> > regards,
> > Raghavendra
> >
> > >
> > > _______________________________________________
> > > Gluster-devel mailing list
> > > Gluster-devel@xxxxxxxxxxx
> > > http://lists.gluster.org/mailman/listinfo/gluster-devel
> >
> 
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel



[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux