Re: [fuse-devel] FORGET criterion?

[Goswin v. B. <gos...@we...>]

Han-Wen Nienhuys <ha...@gm...> writes:

> On Mon, Mar 19, 2012 at 10:24 AM, Goswin von Brederlow
> <gos...@we...> wrote:
>
>>> I notice that the live inode count goes up to 1114.  Then, a
>>>
>>>  echo 3 > /proc/sys/vm/drop_caches
>>>
>>> makes the inode count drop to 96.  When I umount the FS, these last
>>> inodes get duly forgotten, but can't they be forgotten earlier?  Since
>>> I only ran a find on the mount, there is nothing from userspace
>>> holding on to any data.
>>
>> No idea. What if you drop caches again?
>
> nothing.
>
>>> Background: I have a file system being used in production that is
>>> using too much memory for inodes if any process tries to scan the
>>> mount. Are there ways to make FUSE recollect inodes more aggressively,
>>> or is there a way to tune the behavior?  If not, I could imagine that
>>> the daemon could issue some sort of NOTIFY to trigger a forget event.
>>>
>>> thanks!
>>
>> The forget is issued by the kernel independent of fuse and happens when
>> the kernel thinks it is a good time to do so.
>>
>> If your filesystem is using up too much memory then maybe just stop
>> keeping all those inodes cached. Nothing requires you to keep inodes in
>> memory until they get a forget. Just keep your inode+generation number
>> straight.
>
> It's a nice idea, but I'd have to duplicate the liveness logic of the
> kernel; it would be problematic if I got operations on an inode that I
> just threw away.

That depends on the kind of FS you have. A disk based FS will have the
inodes on disk so they can just be read from disk when needed again. If
you have a overlay FS and you generate inodes dynamically then you need
to track them at least as long as the kernel does.

In the later case you have to live with the memory overhead. The best
you can do is do remove them from memory when the kernel sends a forget
and to minimize the amount of data kept per inode.

MfG
        Goswin