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