summaryrefslogtreecommitdiffstats
path: root/extras
diff options
context:
space:
mode:
authorSoumya Koduri <skoduri@redhat.com>2016-02-08 22:33:56 +0530
committerKaleb KEITHLEY <kkeithle@redhat.com>2016-02-23 18:51:11 -0800
commitdb747eba347e2909f4fb4fc28a67adb8f188586a (patch)
tree9556a00d7bb2cdbfc94a3ee292a456ca2e0b5476 /extras
parentdcb13de77d0ac056b588f3eb7414e33afeeb3629 (diff)
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(). Change-Id: Id2c7ab178894a10c0030c143ba71e7813df8d18c Signed-off-by: Soumya Koduri <skoduri@redhat.com> BUG: 1295107 Reviewed-on: http://review.gluster.org/13096 Reviewed-by: jiffin tony Thottan <jthottan@redhat.com> NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org> Reviewed-by: Niels de Vos <ndevos@redhat.com> CentOS-regression: Gluster Build System <jenkins@build.gluster.com> Smoke: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Kaleb KEITHLEY <kkeithle@redhat.com>
Diffstat (limited to 'extras')
0 files changed, 0 insertions, 0 deletions