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.
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.
(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?
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.
A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/18852801
Dave Garnett deleted the linked story in Pivotal Tracker
Planing to keep 3.4.x branch as "internal enhancements" release without any features. So moving these bugs to 3.4.0 target milestone.
CHANGE: http://review.gluster.com/324 (Thanks to Csaba Henk <csaba> for the patch) merged in master by Anand Avati (avati)
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