On Fri, Aug 26, 2016 at 3:01 PM, Piotr Rybicki <piotr.rybicki@xxxxxxxxxxxxxx> 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@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users
--
Pranith
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-users
