[Gluster-users] Gfapi memleaks, all versions

Pranith Kumar Karampuri pkarampu at redhat.com
Fri Aug 26 15:23:45 UTC 2016

On Fri, Aug 26, 2016 at 3:01 PM, Piotr Rybicki <piotr.rybicki at innervision.pl
> wrote:

> W dniu 2016-08-25 o 23:22, Joe Julian pisze:
>> I don't think "unfortunatelly with no attraction from developers" is
>> fair. Most of the leaks that have been reported against 3.7 have been
>> fixed recently. Clearly, with 132 contributors, not all of them can, or
>> should, work on fixing bugs. New features don't necessarily interfere
>> with bug fixes.
>> The solution is to file good bug reports,
>> https://bugzilla.redhat.com/enter_bug.cgi?product=GlusterFS , and
>> include valgrind reports, state dumps, and logs.
>> This is a community, not a company. Nobody's under an obligation to
>> prioritize your needs over the needs of others. What I *have* seen is
>> that the more effort you put in to identifying a problem, the easier it
>> is to find a developer that can help you. If you need help, ask. It's
>> not just developers that can help you. I spend countless hours on IRC
>> helping people and I don't make a dime off doing so.
>> Finally, if you have a bug that's not getting any attention, feel free
>> to email the maintainer of the component you've reported a bug against.
>> Be nice. They're good people and willing to help.
> Hello Joe.
> First, I didn't wish do offend anyone. If one feels this way - I'm sorry
> for that. I just wanted to get attraction to this memleak(s) issue.
> I really like gluster project, and all I wish is to make it better.
> I just filled bug report:
> https://bugzilla.redhat.com/show_bug.cgi?id=1370417

hi Piotr,
         Sorry for the delay in addressing this issue. But this is not
something that is easy to fix. First round of fixing the leaks which was
done by Poornima to free up the inode tables took lot of time(Probably
months, I could be wrong. It was a very big effort) and it was across the
whole project. She also addressed graph deallocation part but it is not
enabled I think (I cced her as well to the thread). We have a new feature
called brick multiplexing that is in the works which makes it very
important to handle this leak, so it will be fixed as part of that
feature/stabilizing the feature in proper way IMO.

        There was a time when all this clean up was not necessary because
the mount process would die anyway. Then when gfapi came in, the process
wouldn't die anymore :-), so we have to fix all the shortcuts we took over
the years to properly fix it. So lot of work :-/. It is something that
needs to be done properly (multi threaded nature of the workloads make it a
bit difficult), because the previous attempts at fixing it caused the
process to die because of double free etc.

> Thank You & best regards
> Piotr Rybicki
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20160826/46613b64/attachment.html>

More information about the Gluster-users mailing list