[Gluster-devel] FUSE nodes TTL and FORGET

[Anand Avati]

On Tue, Jun 12, 2012 at 9:43 PM, Emmanuel Dreyfus <manu at netbsd.org> wrote:

> 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.
>
> 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?
>
>
The Linux kernel uses the second method. That works fine most of the time.
In Linux there is also the option of the userspace filesystem explicitly
hand-picking and invalidating entries which results in FORGET for that
inode (provided it is not ref'd by anything else like calls, fds etc.)

Avati
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20120617/c089e02d/attachment-0003.html>