On 09/18/2014 03:13 PM, Niels de Vos wrote:
On Thu, Sep 18, 2014 at 07:43:00AM +0530, Pranith Kumar Karampuri wrote:
hi,
     Till now the only method I used to find ref leaks effectively is to find
what operation is causing ref leaks and read the code to find if there is a
ref-leak somewhere. Valgrind doesn't solve this problem because it is
reachable memory from inode-table etc. I am just wondering if there is an
effective way anyone else knows of. Do you guys think we need a better
mechanism of finding refleaks? At least which decreases the search space
significantly i.e. xlator y, fop f etc? It would be better if we can come up
with ways to integrate statedump and this infra just like we did for
mem-accounting.

One way I thought was to introduce new apis called
xl_fop_dict/inode/fd_ref/unref (). Each xl keeps an array of num_fops per
inode/dict/fd and increments/decrements accordingly. Dump this info on
statedump.

I myself am not completely sure about this idea. It requires all xlators to
change.

Any ideas?
 From my understanding, you are looking for something like this addition:

     struct _xlator {
             ...
             struct {
                     int64_t inodes[GF_FOP_MAXVALUE - 1];
                     int64_t fds[GF_FOP_MAXVALUE - 1];
                     ...
             } refs;
             ...
     };
Correct.

inode_table_new(.., *xl) gets the xlator passed, so it can in-/decrease
the xl->refs->inodes[_call_frame_t->op] on future inode_new(),
inode_ref() and inode_unref() calls.
Not like this. We are going to provide apis like
xl_fop_inode_ref(inode_t*, xlator_t*, fop op)
xl_fop_inode_unref(inode_t*, xlator_t*, fop op) and so on for fd, dict.

xlator code has to change :-(. That is the problem.

Some of the difficulties I see ATM, are:
- how to get to the _call_frame_t->op
- correctly accounting FOPs like OPEN/CLOSE

Mainly just tossing the idea here, maybe I'm completely missing the
point, or there are other issues why this would be an impossible
solution.

Cheers,
Niels

_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel

Reply via email to