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;
...
};
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.
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@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
