Bug 762277 - (GLUSTER-545) garbage collect client side inode table by means of the reverse invalidation proto enhancement
garbage collect client side inode table by means of the reverse invalidation ...
Status: CLOSED CURRENTRELEASE
Product: GlusterFS
Classification: Community
Component: fuse (Show other bugs)
mainline
All Linux
low Severity low
: ---
: ---
Assigned To: Csaba Henk
Anush Shetty
:
Depends On:
Blocks: 817967
  Show dependency treegraph
 
Reported: 2010-01-15 01:09 EST by Csaba Henk
Modified: 2013-07-24 13:28 EDT (History)
5 users (show)

See Also:
Fixed In Version: glusterfs-3.4.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-24 13:28:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Csaba Henk 2010-01-15 01:09:47 EST
The inode tree in glusterfs client must be kept in sync with kernel side inode tree. In the traditional strict "kernel is client, glusterfs is server" setup the tree layout was managed by the kernel and it was up to the kernel when to get rid of unused inodes. Now as we have reverse (FUSE server initiated) invalidation added to the FUSE protocol, it's possible to hint the kernel from server side by means of invalidation messages to drop certain inodes. That means we can take the LRU algorithm used with server side inode tables and put into use for the client inode table as well.
Comment 1 Amar Tumballi 2011-04-25 05:32:51 EDT
Please update the status of this bug as its been more than 6months since its filed (bug id < 2000)

Please resolve it with proper resolution if its not valid anymore. If its still valid and not critical, move it to 'enhancement' severity.
Comment 2 Csaba Henk 2011-04-25 06:17:14 EDT
(In reply to comment #1)
> Please update the status of this bug as its been more than 6months since its
> filed (bug id < 2000)
> 
> Please resolve it with proper resolution if its not valid anymore. If its still
> valid and not critical, move it to 'enhancement' severity.

it is an enhancement as of now, what's wrong then?
Comment 3 Jeff Darcy 2011-06-06 08:55:36 EDT
Heard from a Fedora user on IRC who claims to be hitting this for real on a large migration of files into GlusterFS.  He reports unbounded inode-related memory use on both clients and servers.  I'm trying to get him to provide more details, but in the meantime this seems to be more than a theoretical problem.
Comment 4 Dave Garnett 2011-09-26 08:01:45 EDT
A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/18852801
Comment 5 Dave Garnett 2011-09-26 08:53:26 EDT
Dave Garnett deleted the linked story in Pivotal Tracker
Comment 6 Amar Tumballi 2011-09-27 01:50:03 EDT
Planing to keep 3.4.x branch as "internal enhancements" release without any features. So moving these bugs to 3.4.0 target milestone.
Comment 7 Anand Avati 2011-12-12 05:15:21 EST
CHANGE: http://review.gluster.com/324 (Thanks to Csaba Henk <csaba@gluster.com> for the patch) merged in master by Anand Avati (avati@gluster.com)
Comment 8 Anush Shetty 2012-05-31 05:51:57 EDT
Verified with 3.3.0qa45

/mnt# touch dot

/mnt# ls dot
dot

/mnt# setfattr -n inode-invalidate dot

[2012-05-31 15:18:58.373743] T [fuse-bridge.c:489:fuse_attr_cbk] 0-glusterfs-fuse: 30: LOOKUP() / => 1
[2012-05-31 15:18:58.387563] T [fuse-bridge.c:2663:fuse_setxattr] 0-fuse: got request to invalidate 140160608882880
[2012-05-31 15:18:58.387641] T [fuse-bridge.c:206:fuse_invalidate] 0-glusterfs-fuse: INVALIDATE entry: 1/dot
[2012-05-31 15:18:58.387683] T [fuse-bridge.c:407:fuse_forget] 0-glusterfs-fuse: 32: FORGET 140160608882880/3

Note You need to log in before you can comment on or make changes to this bug.