Description of problem: Currently fuse-bridge has an lru limit of the inode table as infinite. This means we are dependent on kernel to send forgets even though the inode is not active. However, we can implement garbage collection of inodes in lru list of itable. We can ask kernel to send a forget by calling inode/entry_invalidate on the inode. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
*** Bug 1579151 has been marked as a duplicate of this bug. ***
This is good for validating this feature. But to be complete, you need to complete negative tests, like, giving it an option of negative values. String values, etc and see how the process takes it.
Tried mounting the volume using the '-olru-limit' option with invalid inputs for the option. Following are the observations: 1. Alphabets as inputs - Mount fails with "glusterfs: unknown LRU limit option abc" error 2. Special characters as inputs (eg. %, &, !, @, etc.) - Mount fails with "glusterfs: unknown LRU limit option !" error 3. Decimal values (eg. 1.5) - Mount fails with "glusterfs: unknown LRU limit option 1.5" error 4. Empty string as value - Error message is displayed as "Invalid option lru-limit". Although there is no mount failed message, the output of "df" command doesn't list the mount and the mount is unsuccessful. Polarion test case has been attached with the bug, please review the test case.
Vinayak, Looks fine about invalid option tests. As a add-on one can run memory consumption runs in longevity tests, where there are more than a million files being used. I am fine to mark this bug as VERIFIED.
Based on comment 10 , comment 12 and comment 14 , moving this bug to VERIFIED.
Thanks for reviewing the doctext.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:0658
Cal, Sorry missed your needinfo earlier. Yes, this addresses the concerns raised in bz1632465. Please let customer know that client memory usage is controlled now onwards from RHGS 3.4.4 releases. Will also close the bug (1632465) as CURRENT_RELEASE for reducing the confusion.