Re: [Gluster-devel] [features/locks] Fetching lock info in lookup
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 wrote:
>
>
> On Wed, Jun 20, 2018 at 9:06 AM, Raghavendra Gowdappa > 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...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..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
Re: [Gluster-devel] [features/locks] Fetching lock info in lookup
On Wed, Jun 20, 2018 at 9:06 AM, Raghavendra Gowdappa
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...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..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] [features/locks] Fetching lock info in lookup
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...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..granted-locks" - number of granted inodelks on
"basename"
Thoughts?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1581306#c28
regards,
Raghavendra
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Coverity covscan for 2018-06-19-64d21769 (master branch)
GlusterFS Coverity covscan results for the master branch are available from http://download.gluster.org/pub/gluster/glusterfs/static-analysis/master/glusterfs-coverity/2018-06-19-64d21769/ Coverity covscan results for other active branches are also available at http://download.gluster.org/pub/gluster/glusterfs/static-analysis/ ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Fedora builds and rawhide builds
Hello,
We ran into a problem where builds for F28 and above will not build on
CentOS7 chroots. We caught this when F28 was rawhide but deemed it not yet
important enough to fix, however, recent developments have forced us to
make the switch. Our Fedora builds will also switch to using F28.
We have 10 new builders builder{40..49}.int.rht.gluster.org, all of which
run F28. These will be currently used for Fedora builds (they build with
libtirpc and rpcgen) and for the upcoming clang-format jobs.
Please let us know if you notice anything wrong the voting patterns for
smoke jobs.
--
nigelb
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel
