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

[Raghavendra Gowdappa]

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 <rgowdapp at redhat.com>
wrote:

>
>
> On Wed, Jun 20, 2018 at 12:06 PM, Krutika Dhananjay <kdhananj at 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 <atumball at redhat.com>
>> wrote:
>>
>>>
>>>
>>> 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
>>>>
>>>>
>>> _______________________________________________
>>> Gluster-devel mailing list
>>> Gluster-devel at gluster.org
>>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180620/52fb7227/attachment.html>