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

2019-05-27 Thread Pranith Kumar Karampuri
On Sat, May 25, 2019 at 10:22 AM Pranith Kumar Karampuri < pkara...@redhat.com> wrote: > > > 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

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

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

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

2019-05-24 Thread Pranith Kumar Karampuri
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