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: Anand Avati
Subject: Re: [Gluster-devel] FUSE nodes TTL and FORGET
Date: Sun, 17 Jun 2012 22:46:58 -0700



On Tue, Jun 12, 2012 at 9:43 PM, Emmanuel Dreyfus <address@hidden> 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

reply via email to

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