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