[Gluster-devel] [features/locks] Fetching lock info in lookup
rgowdapp at redhat.com
Wed Jun 20 07:28:25 UTC 2018
On Wed, Jun 20, 2018 at 12:06 PM, Krutika Dhananjay <kdhananj at redhat.com>
> 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
> On Wed, Jun 20, 2018 at 9:17 AM, Amar Tumballi <atumball at redhat.com>
>> On Wed, Jun 20, 2018 at 9:06 AM, Raghavendra Gowdappa <
>> rgowdapp at redhat.com> wrote:
>>> We've a requirement in DHT  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
>>> In lookup request path following key value pairs will be passed in
>>> * "glusterfs.lock.type"
>>> - values can be "glusterfs.posix", "glusterfs.inodelk",
>>> * If the value of "glusterfs.lock.type" is "glusterfs.entrylk", then
>>> basename is passed as a value in xdata_req for key
>>> * 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
>>> * "glusterfs.granted-locks" - Information should be limited to granted
>>> * If necessary other information about granted locks, blocked locks can
>>> be added. Since, there is no requirement for now, I am not adding these
>>> 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"
>> 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.
>>>  https://bugzilla.redhat.com/show_bug.cgi?id=1581306#c28
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel