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