gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] FUSE nodes TTL and FORGET


From: Raghavendra Gowdappa
Subject: Re: [Gluster-devel] FUSE nodes TTL and FORGET
Date: Mon, 18 Jun 2012 00:38:14 -0400 (EDT)

Hi Emmanuel,

----- Original Message -----
> From: "Emmanuel Dreyfus" <address@hidden>
> To: address@hidden
> Sent: Wednesday, June 13, 2012 10:13:24 AM
> Subject: [Gluster-devel] FUSE nodes TTL and FORGET
> 
> Hi
> 
> I have a concern with how NetBSD FUSE hande nodes TTL and FORGET.
> 
> When we create/mkdir/mknod/lookup a node, we get a TTL for it (this
> is
> the entry_valid field in struct fuse_entry_out). The kernel should
> not
> lookup the node again until the TTL expires.
> 
> This means that once the TTL is expired, the kernel must do a lookup,
> again, and therefore that the previously obtained node should not be
> used. That suggests a FUSE FORGET can be sent for it as soon as (the
> kernel does not reference it AND TTL is expired).
> 
> For now, NetBSD is lazy about the FUSE FORGET. It is sent when it
> reaches the vnode limit and needs to make room. This means there are
> a
> lot of stale nodes that remain in the kernel and in glusterfs,
> consuming
> memory. I can switch to a behavior where the FUSE FORGET are sent
> aggressively as soon as (kernel reference drops to 0 and TTL is
> expired), but this will cause a lot of useless FUSE messages, with an
> impact on the performance front.

I am little bit confused here about uselessness of FORGET messages. You have 
mentioned yourselves that we need this approach to limit memory consumption 
(which is true since many resources are stored in context of gluster inode, 
which will be freed in forget). Also, since duration for which an inode is 
cached can be configured using TTL values, shouldn't this the approach we be 
following?

> 
> To make it clear, here is what we have with lazy FORGET policy:
> LOOKUP a
> INACTIVE a
> (ttl expires)
> LOOKUP a
> INACTIVE a
> (ttl expires)
> LOOKUP a
> ...
> 
> And here is what I get wth aggressive FORGET policy
> LOOKUP a
> INACTIVE a
> (ttl expires)
> FORGET a  <- extra useless FORGET
> LOOKUP a
> INACTIVE a
> (ttl expires)
> FORGET a  <- extra useless FORGET
> LOOKUP a
> ...
> 
> What do you think is the best approach? How does the Linux kernel
> handles the situation?
> 
>
> --
> Emmanuel Dreyfus
> http://hcpnet.free.fr/pubz
> address@hidden
> 
> _______________________________________________
> Gluster-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
> 

regards,
Raghavendra.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]