[Bugs] [Bug 1311441] Fix mem leaks related to gfapi applications

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1311441



--- Comment #6 from Vijay Bellur <vbellur at redhat.com> ---
COMMIT: http://review.gluster.org/13506 committed in release-3.7 by Kaleb
KEITHLEY (kkeithle at redhat.com) 
------
commit 6f12a5767f6912f6913cd9dfa4c6a5484a766000
Author: Soumya Koduri <skoduri at redhat.com>
Date:   Mon Feb 8 22:33:56 2016 +0530

    gfapi: Use inode_forget in case of handle objects

    Currently with gfapi, even if applications release their
    reference on paritular inode entries, those entries never
    get destroyed as they shall always have positive nlookup
    count unless inode_table exceeds lru limit.

    Since inodes and their contexts can consume considerable
    amount of memory, applications may end up consuming lot of
    memory and may even get OOM killed.

    To avoid that, have considered below approaches (for handle based access)-
    a) Do 'inode_lookup' only if the corresponding inode is created
    for the first time and forget it during close of the handle

    This shall not work as multiple handle objects can refer to
    same inode entry and inode_forget from second handle object
    onwards shall result in assert.

    b) Do 'inode_lookup' during a handle or fd creation

    But this approach shall affect the performance of the fops which
    operate on neither handle nor fd.

    c) current approach taken-
    Applications using glfs handle objects hold a reference
    on corresponding inode entries. Hence it is safe to forget
    those inodes and make nlookup count to '0' while trying to
    delete those handle objects. That way the last unref (i.e,
    from the last handle close) shall result in inode_destroy().

    This is backport of the below patch
        - http://review.gluster.org/13096

    Change-Id: Id2c7ab178894a10c0030c143ba71e7813df8d18c
    Signed-off-by: Soumya Koduri <skoduri at redhat.com>
    BUG: 1311441
    Reviewed-on: http://review.gluster.org/13096
    Reviewed-by: jiffin tony Thottan <jthottan at redhat.com>
    Reviewed-by: Niels de Vos <ndevos at redhat.com>
    Reviewed-by: Kaleb KEITHLEY <kkeithle at redhat.com>
    Reviewed-on: http://review.gluster.org/13506
    Smoke: Gluster Build System <jenkins at build.gluster.com>
    NetBSD-regression: NetBSD Build System <jenkins at build.gluster.org>
    CentOS-regression: Gluster Build System <jenkins at build.gluster.com>

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.