Bug 1390614

Summary:	api: inode_table is too big
Product:	[Community] GlusterFS	Reporter:	Kaleb KEITHLEY <kkeithle>
Component:	libgfapi	Assignee:	bugs <bugs>
Status:	CLOSED UPSTREAM	QA Contact:	Sudhir D <sdharane>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	mainline	CC:	bugs, happe, ndevos, pavel.cernohorsky, srangana
Target Milestone:	---	Keywords:	FutureFeature, Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
URL:	http://lists.gluster.org/pipermail/gluster-devel/2017-March/052228.html
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-11-20 09:10:32 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1360272

Description Kaleb KEITHLEY 2016-11-01 14:13:45 UTC

Description of problem:

Pavel Cernohorsky sent email to gluster-users:

...
colleague of mine found out the problem is this line:

itable = inode_table_new (131072, new_subvol);

in glfs-master.c (graph_setup function). That hard-coded number is huge! And looking at the history of Gluster sources, it seems that this number used to be a number of bytes, but it became number of inodes, but someone forgot to change this hard-coded value!
...



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Pavel Černohorský 2016-11-01 14:28:24 UTC

Additional info can be found in the original mailing list post (http://www.gluster.org/pipermail/gluster-users/2016-October/028818.html).

Short summary:
Using libgfapi in application which operates on lot of different files consumes extreme amount of memory, just opening, reading few bytes and closing can easily cause the application to consume ~hundreds of MBs which are never freed.

The value should be either lower on configurable during the library initialization.

Comment 2 Niels de Vos 2016-11-08 21:02:34 UTC

We have different use-cases for libgfapi. Both Samba and NFS-Ganesha would benefit from a large inode-table, but QEMU just needs a few inodes. Tuning the default will be difficult, so I guess it would be best to add a function in libgfapi so that the application can decide how big the inode-table needs to be.

Shyam, care to add your thoughts?

Comment 3 Shyamsundar 2016-11-09 14:44:35 UTC

(In reply to Niels de Vos from comment #2)
> We have different use-cases for libgfapi. Both Samba and NFS-Ganesha would
> benefit from a large inode-table, but QEMU just needs a few inodes. Tuning
> the default will be difficult, so I guess it would be best to add a function
> in libgfapi so that the application can decide how big the inode-table needs
> to be.

Agree.

As for the API, my thoughts would be to have a generic config API, with various key, value pairs. So that we do not have an API explosion for other such parameters that need to be controlled per instance.

Comment 4 Niels de Vos 2017-03-06 09:14:54 UTC

Discussion about the design for the API can be found at http://lists.gluster.org/pipermail/gluster-devel/2017-March/052228.html

Comment 5 Vijay Bellur 2018-11-20 09:43:23 UTC

Migrated to github:

https://github.com/gluster/glusterfs/issues/603

Please follow the github issue for further updates on this bug.