[Gluster-devel] Preview request for cleaning up the global timer-wheel
Hi Poornima and others, Could someone please review the patch that adds reference counting to the timer-wheel structure that is used by glusterfs_ctx_t? https://review.gluster.org/17068 > core: make the per glusterfs_ctx_t timer-wheel refcounted > > xlators can use a 'global' timer-wheel for scheduling events. This > timer-wheel is managed per glusterfs_ctx_t, but does not need to be > allocated for every graph. When an xlator wants to use the timer-wheel, > it will be instanciated on demand, and provided to xlators that request > it later on. > > By adding a reference counter to the glusterfs_ctx_t for the > timer-wheel, the threads and structures can be cleaned up when the last > xlator does not have a need for it anymore. In general, the xlators > request the timer-wheel in init(), and they should return it in fini(). > > Because the timer-wheel is managed per glusterfs_ctx_t, the functions > can be added to ctx.c and do not need to live in their very minimal > tw.[ch] files. > > Change-Id: I19d225b39aaa272d9005ba7adc3104c3764f1572 > BUG: 1442788 > Reported-by: Poornima G > Signed-off-by: Niels de Vos Thanks, Niels signature.asc Description: PGP signature ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] 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? 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) 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) ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] About spread count, lookup and layout
- Original Message - > From: "Tahereh Fattahi" > To: "Gluster Devel" > Sent: Sunday, April 30, 2017 8:03:15 AM > Subject: [Gluster-devel] 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@gluster.org > http://lists.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] [DHT] The myth of two hops for linkto file resolution
All, Its a common perception that the resolution of a file having linkto file on the hashed-subvol requires two hops: 1. client to hashed-subvol. 2. client to the subvol where file actually resides. While it is true that a fresh lookup behaves this way, the other fact that get's ignored is that fresh lookups on files are almost always prevented by readdirplus. Since readdirplus picks the dentry from the subvolume where actual file (data-file) resides, the two hop cost is most likely never witnessed by the application. A word of caution is that I've not done any testing to prove this observation :). regards, Raghavendra ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] 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. I had thought that lookup everywhere is for searching file not for layout. 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) On Sun, Apr 30, 2017 at 8:12 AM, Raghavendra Gowdappa wrote: > > > - Original Message - > > From: "Tahereh Fattahi" > > To: "Gluster Devel" > > Sent: Sunday, April 30, 2017 8:03:15 AM > > Subject: [Gluster-devel] 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@gluster.org > > http://lists.gluster.org/mailman/listinfo/gluster-devel > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] About spread count, lookup and layout
- Original Message - > From: "Tahereh Fattahi" > To: "Raghavendra Gowdappa" > Cc: "Gluster Devel" > Sent: Sunday, April 30, 2017 10:04:25 AM > Subject: Re: [Gluster-devel] 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 > wrote: > > > > > > > - Original Message - > > > From: "Tahereh Fattahi" > > > To: "Gluster Devel" > > > Sent: Sunday, April 30, 2017 8:03:15 AM > > > Subject: [Gluster-devel] 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@gluster.org > > > http://lists.gluster.org/mailman/listinfo/gluster-devel > > > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
