d49b41e817
The inode LRU mechanism is moot in fuse xlator (ie. there is no limit for the LRU list), as fuse inodes are referenced from kernel context, and thus they can only be dropped on request of the kernel. This might results in a high number of passive inodes which are useless for the glusterfs client, causing a significant memory overhead. This change tries to remedy this by extending the LRU semantics and allowing to set a finite limit on the fuse inode LRU. A brief history of problem: When gluster's inode table was designed, fuse didn't have any 'invalidate' method, which means, userspace application could never ask kernel to send a 'forget()' fop, instead had to wait for kernel to send it based on kernel's parameters. Inode table remembers the number of times kernel has cached the inode based on the 'nlookup' parameter. And 'nlookup' field is not used by no other entry points (like server-protocol, gfapi etc). Hence the inode_table of fuse module always has to have lru-limit as '0', which means no limit. GlusterFS always had to keep all inodes in memory as kernel would have had a reference to it. Again, the reason for this is, kernel's glusterfs inode reference was pointer of 'inode_t' structure in glusterfs. As it is a pointer, we could never free it (to prevent segfault, or memory corruption). Solution: In the inode table, handle the prune case of inodes with 'nlookup' differently, and call a 'invalidator' method, which in this case is fuse_invalidate(), and it sends the request to kernel for getting the forget request. When the kernel sends the forget, it means, it has dropped all the reference to the inode, and it will send the forget with the 'nlookup' parameter too. We just need to make sure to reduce the 'nlookup' value we have when we get forget. That automatically cause the relevant prune to happen. Credits: Csaba Henk, Xavier Hernandez, Raghavendra Gowdappa, Nithya B fixes: bz#1560969 Change-Id: Ifee0737b23b12b1426c224ec5b8f591f487d83a2 Signed-off-by: Amar Tumballi <amarts@redhat.com>
Gluster
Gluster is a software defined distributed storage that can scale to several petabytes. It provides interfaces for object, block and file storage.
Development
Contributions to gluster in the form of patches and new feature additions can be made by following steps outlined at Developers Guide.
Documentation
The Gluster documentation can be found at Gluster Docs.
Deployment
Quick instructions to build and install can be found in INSTALL file.
Testing
GlusterFS source contains some functional tests under tests/ directory. All
these tests are run against every patch submitted for review. If you want your
patch to be tested, please add a .t test file as part of your patch submission.
You can also submit a patch to only add a .t file for the test case you are
aware of.
To run these tests, on your test-machine, just run ./run-tests.sh. Don't run
this on a machine where you have 'production' glusterfs is running, as it would
blindly kill all gluster processes in each runs.
If you are sending a patch, and want to validate one or few specific tests, then run a single test by running the below command.
bash# /bin/bash ${path_to_gluster}/tests/basic/rpc-coverage.t
You can also use prove tool if available in your machine, as follows.
bash# prove -vmfe '/bin/bash' ${path_to_gluster}/tests/basic/rpc-coverage.t
Maintainers
The list of Gluster maintainers is available in MAINTAINERS file.
License
Gluster is dual licensed under GPLV2 and LGPLV3+.
Please visit the Gluster Home Page to find out more about Gluster.