On Wed, Jun 20, 2018 at 9:09 PM, Xavi Hernandez <xhernan...@redhat.com> wrote:
> On Wed, Jun 20, 2018 at 4:29 PM Raghavendra Gowdappa <rgowd...@redhat.com> > wrote: > >> Krutika, >> >> This patch doesn't seem to be getting counts per domain, like number of >> inodelks or entrylks acquired in a domain "xyz". Am I right? If per domain >> stats are not available, passing interested domains in xdata_req would be >> needed. Any suggestions on that? >> > > We have GLUSTERFS_INODELK_DOM_COUNT. Its data should be a domain name for > which we want to know the number of inodelks (the count is returned into > GLUSTERFS_INODELK_COUNT though). > > It only exists for inodelk. If you need it for entrylk, it would need to > be implemented. > Yes. Realised that after going through the patch a bit more deeply. Thanks. I'll implement a domain based entrylk count. > Xavi > > >> regards, >> Raghavendra >> >> On Wed, Jun 20, 2018 at 12:58 PM, Raghavendra Gowdappa < >> rgowd...@redhat.com> wrote: >> >>> >>> >>> On Wed, Jun 20, 2018 at 12:06 PM, Krutika Dhananjay <kdhan...@redhat.com >>> > wrote: >>> >>>> We do already have a way to get inodelk and entrylk count from a bunch >>>> of fops, introduced in http://review.gluster.org/10880. >>>> Can you check if you can make use of this feature? >>>> >>> >>> Thanks Krutika. Yes, this feature meets DHT's requirement. We might need >>> a GLUSTERFS_PARENT_INODELK, but that can be easily added along the lines of >>> other counts. If necessary I'll send a patch to implement >>> GLUSTERFS_PARENT_INODELK. >>> >>> >>>> -Krutika >>>> >>>> >>>> On Wed, Jun 20, 2018 at 9:17 AM, Amar Tumballi <atumb...@redhat.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Jun 20, 2018 at 9:06 AM, Raghavendra Gowdappa < >>>>> rgowd...@redhat.com> wrote: >>>>> >>>>>> All, >>>>>> >>>>>> We've a requirement in DHT [1] to query the number of locks granted >>>>>> on an inode in lookup fop. I am planning to use xdata_req in lookup to >>>>>> pass >>>>>> down the relevant arguments for this query. I am proposing following >>>>>> signature: >>>>>> >>>>>> In lookup request path following key value pairs will be passed in >>>>>> xdata_req: >>>>>> * "glusterfs.lock.type" >>>>>> - values can be "glusterfs.posix", "glusterfs.inodelk", >>>>>> "glusterfs.entrylk" >>>>>> * If the value of "glusterfs.lock.type" is "glusterfs.entrylk", then >>>>>> basename is passed as a value in xdata_req for key >>>>>> "glusterfs.entrylk.basename" >>>>>> * key "glusterfs.lock-on?" will differentiate whether the lock >>>>>> information is on current inode ("glusterfs.current-inode") or >>>>>> parent-inode >>>>>> ("glusterfs.parent-inode"). For a nameless lookup >>>>>> "glusterfs.parent-inode" >>>>>> is invalid. >>>>>> * "glusterfs.blocked-locks" - Information should be limited to >>>>>> blocked locks. >>>>>> * "glusterfs.granted-locks" - Information should be limited to >>>>>> granted locks. >>>>>> * If necessary other information about granted locks, blocked locks >>>>>> can be added. Since, there is no requirement for now, I am not adding >>>>>> these >>>>>> keys. >>>>>> >>>>>> Response dictionary will have information in following format: >>>>>> * "glusterfs.entrylk.<gfid>.<basename>.granted-locks" - number of >>>>>> granted entrylks on inode "gfid" with "basename" (usually this value will >>>>>> be either 0 or 1 unless we introduce read/write lock semantics). >>>>>> * "glusterfs.inodelk.<gfid>.granted-locks" - number of granted >>>>>> inodelks on "basename" >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> >>>>> I personally feel, it is good to get as much information possible in >>>>> lookup, so it helps to take some high level decisions better, in all >>>>> translators. So, very broad answer would be to say go for it. The main >>>>> reason the xdata is provided in all fops is to do these extra information >>>>> fetching/overloading anyways. >>>>> >>>>> As you have clearly documented the need, it makes it even better to >>>>> review and document it with commit. So, all for it. >>>>> >>>>> Regards, >>>>> Amar >>>>> >>>>> >>>>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1581306#c28 >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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