[Gluster-devel] [features/locks] Fetching lock info in lookup

[Amar Tumballi]

On Wed, Jun 20, 2018 at 9:06 AM, Raghavendra Gowdappa <rgowdapp at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180620/2c495c5a/attachment.html>