Re: [Gluster-devel] making frame->root->unique more effective in debugging hung frames

2019-05-24 Thread Pranith Kumar Karampuri
On Fri, May 24, 2019 at 10:57 PM FNU Raghavendra Manjunath <
rab...@redhat.com> wrote:

>
> The idea looks OK. One of the things that probably need to be considered
> (more of an implementation detail though) is how to generate
> frame->root->unique.
>
> Because, for fuse, frame->root->unique is obtained by finh->unique which
> IIUC is got from the incoming fop from kernel itself.
> For protocol/server IIUC frame->root->unique is got from req->xit of the
> rpc request, which itself is obtained from transport->xid of the
> rpc_transport_t structure (and from my understanding, the transport->xid is
> just incremented by everytime a
> new rpc request is created).
>
> Overall the suggestion looks fine though.
>

I am planning to do the same thing transport->xid does. I will send out the
patch


> Regards,
> Raghavendra
>
>
> On Fri, May 24, 2019 at 2:27 AM Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
>> Hi,
>> At the moment new stack doesn't populate frame->root->unique in
>> all cases. This makes it difficult to debug hung frames by examining
>> successive state dumps. Fuse and server xlator populate it whenever they
>> can, but other xlators won't be able to assign one when they need to create
>> a new frame/stack. Is it okay to change create_frame() code to always
>> populate it with an increasing number for this purpose?
>>  I checked both fuse and server xlator use it only in gf_log() so it
>> doesn't seem like there is any other link between frame->root->unique and
>> the functionality of fuse, server xlators.
>>   Do let me know if I missed anything before sending this change.
>>
>> --
>> Pranith
>> ___
>>
>> Community Meeting Calendar:
>>
>> APAC Schedule -
>> Every 2nd and 4th Tuesday at 11:30 AM IST
>> Bridge: https://bluejeans.com/836554017
>>
>> NA/EMEA Schedule -
>> Every 1st and 3rd Tuesday at 01:00 PM EDT
>> Bridge: https://bluejeans.com/486278655
>>
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> https://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>>

-- 
Pranith
___

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/836554017

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/486278655

Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel



Re: [Gluster-devel] making frame->root->unique more effective in debugging hung frames

2019-05-24 Thread FNU Raghavendra Manjunath
The idea looks OK. One of the things that probably need to be considered
(more of an implementation detail though) is how to generate
frame->root->unique.

Because, for fuse, frame->root->unique is obtained by finh->unique which
IIUC is got from the incoming fop from kernel itself.
For protocol/server IIUC frame->root->unique is got from req->xit of the
rpc request, which itself is obtained from transport->xid of the
rpc_transport_t structure (and from my understanding, the transport->xid is
just incremented by everytime a
new rpc request is created).

Overall the suggestion looks fine though.

Regards,
Raghavendra


On Fri, May 24, 2019 at 2:27 AM Pranith Kumar Karampuri 
wrote:

> Hi,
> At the moment new stack doesn't populate frame->root->unique in
> all cases. This makes it difficult to debug hung frames by examining
> successive state dumps. Fuse and server xlator populate it whenever they
> can, but other xlators won't be able to assign one when they need to create
> a new frame/stack. Is it okay to change create_frame() code to always
> populate it with an increasing number for this purpose?
>  I checked both fuse and server xlator use it only in gf_log() so it
> doesn't seem like there is any other link between frame->root->unique and
> the functionality of fuse, server xlators.
>   Do let me know if I missed anything before sending this change.
>
> --
> Pranith
> ___
>
> Community Meeting Calendar:
>
> APAC Schedule -
> Every 2nd and 4th Tuesday at 11:30 AM IST
> Bridge: https://bluejeans.com/836554017
>
> NA/EMEA Schedule -
> Every 1st and 3rd Tuesday at 01:00 PM EDT
> Bridge: https://bluejeans.com/486278655
>
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
___

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/836554017

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/486278655

Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel