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. 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