Bug 762277 (GLUSTER-545)

Summary:	garbage collect client side inode table by means of the reverse invalidation proto enhancement
Product:	[Community] GlusterFS	Reporter:	Csaba Henk <csaba>
Component:	fuse	Assignee:	Csaba Henk <csaba>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Anush Shetty <ashetty>
Severity:	low	Docs Contact:
Priority:	low
Version:	mainline	CC:	amarts, gluster-bugs, jdarcy, pavan, tejas
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	glusterfs-3.4.0	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-07-24 17:28:48 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:
Bug Blocks:	817967

Description Csaba Henk 2010-01-15 06:09:47 UTC

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 09:32:51 UTC

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 10:17:14 UTC

(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 12:55:36 UTC

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 12:01:45 UTC

A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/18852801

Comment 5 Dave Garnett 2011-09-26 12:53:26 UTC

Dave Garnett deleted the linked story in Pivotal Tracker

Comment 6 Amar Tumballi 2011-09-27 05:50:03 UTC

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 10:15:21 UTC

CHANGE: http://review.gluster.com/324 (Thanks to Csaba Henk <csaba> for the patch) merged in master by Anand Avati (avati)

Comment 8 Anush Shetty 2012-05-31 09:51:57 UTC

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