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

[Krutika Dhananjay]

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 <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/da8d2658/attachment.html>