<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Mar 31, 2017 7:05 PM, "Niels de Vos" <<a href="mailto:ndevos@redhat.com">ndevos@redhat.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">On Fri, Mar 31, 2017 at 01:24:41PM +0000, Atin Mukherjee wrote:<br>
> On Fri, 31 Mar 2017 at 18:15, Niels de Vos <<a href="mailto:ndevos@redhat.com">ndevos@redhat.com</a>> wrote:<br>
><br>
> > On Fri, Mar 31, 2017 at 02:34:04PM +0530, Sanoj Unnikrishnan wrote:<br>
> > > +Mohit<br>
> > > Mohit had written a similar script to RCA an issue couple of months back.<br>
> > ><br>
> > > It would help if we placed the scripts, tapsets in the source tree itself<br>
> > > (maybe in a directory under glusterfs/extras/).<br>
> > > We could also have the tapset packaged into debuginfo packages and<br>
> > deployed<br>
> > > under /usr/share/systemtap/ path upon installation.<br>
> ><br>
> > Yes, or we can place them in their own repository. I have a<br>
> > gluster-debug repository where I plan to put tools I use for debugging.<br>
> > This repository may well live at the Gluster organization on GitHub too.<br>
> ><br>
> > <a href="https://github.com/nixpanic/gluster-debug" rel="noreferrer" target="_blank">https://github.com/nixpanic/<wbr>gluster-debug</a><br>
> ><br>
> > Many of the tools we use for debugging should not be version specific,<br>
> > so having them in the glusterfs repository might be a little awkward?<br>
> ><br>
> > What are the opinions of others?<br>
><br>
><br>
> My personal preference would be to host it under one central repo instead<br>
> of individual github accounts. Versioning and such other issues can be<br>
> tackled having good documentation around these tools.<br>
<br>
</div>Yes, of course. I intended to explain we put all the debug tools in<br>
<a href="https://github.com/gluster/gluster-debug" rel="noreferrer" target="_blank">https://github.com/gluster/<wbr>gluster-debug</a> (does not exist yet). Those<br>
tools can then also include debug utilities for related projects, not<br>
only for the core glusterfs repository.<br>
<font color="#888888"><br>
Niels<br>
</font><div class="elided-text"><br>
><br>
><br>
> ><br>
> > Thanks,<br>
> > Niels<br>
> ><br>
> ><br>
> > > Regards,<br>
> > > Sanoj<br>
> > ><br>
> > > On Fri, Mar 31, 2017 at 12:44 PM, Sonal Arora <<a href="mailto:sarora@redhat.com">sarora@redhat.com</a>> wrote:<br>
> > ><br>
> > > > Hi,<br>
> > > ><br>
> > > > I am working on finding ways to indentify ref leaks in glusterfs.<br>
> > > ><br>
> > > > Description of Issue :<br>
> > <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1417539" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/<wbr>show_bug.cgi?id=1417539</a><br>
> > > ><br>
> > > > Goal : To make script which could detect all kind of ref leaks.<br>
> > > ><br>
> > > > Script : <a href="https://github.com/SonaArora/Tracing-userspace-app/blob/" rel="noreferrer" target="_blank">https://github.com/SonaArora/<wbr>Tracing-userspace-app/blob/</a><br>
> > > > master/ref-leak/try8-modified<br>
> > > > The above script is a POC program to depict the idea of how to identify<br>
> > > > leaks. Script is probing dict_ref() and dict_unref() and keeping a<br>
> > track of<br>
> > > > the pointers, back traces which are referenced/dereferenced by above<br>
> > > > functions. If the count of refs is unequal to unrefs for each<br>
> > pointer,it<br>
> > > > will print all the traces corresponding to the leaked pointer.<br>
> > > > Output : <a href="https://github.com/SonaArora/Tracing-userspace-" rel="noreferrer" target="_blank">https://github.com/SonaArora/<wbr>Tracing-userspace-</a><br>
> > > > app/blob/master/ref-leak/<wbr>output-refleak<br>
> > > > I am working on post processing the output - to filter only the leaked<br>
> > > > traces and to write the output after every few hours into a file.<br>
> > > > The script can be extended to all objects being referenced (like<br>
> > > > inodes/fds).<br>
> > > ><br>
> > > > End Goal : Future goal is to make it more versatile, dynamic and light<br>
> > > > weight so that it can be even utilized on production environments<br>
> > without<br>
> > > > utilizing much of the system resources.<br>
> > > ><br>
> > > > Request your comments and suggestions.<br>
> > > ><br>
> > > > Best<br>
> > > > -Sonal<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > ______________________________<wbr>_________________<br>
> > > > Gluster-devel mailing list<br>
> > > > <a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
> > > > <a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/<wbr>mailman/listinfo/gluster-devel</a><br>
> > > ><br>
> > ______________________________<wbr>_________________<br>
> > Gluster-devel mailing list<br>
> > <a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
> > <a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/<wbr>mailman/listinfo/gluster-devel</a><br>
><br>
> --<br>
> - Atin (atinm)<br></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">That's a good idea to put all such kind of work in one place so that everyone can utilize this.</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text">
</div></blockquote></div><br></div></div></div>