Re: [PATCH v8] fuse: add more control over cache invalidation behaviour

[Luis Henriques]

Hi Miklos,

On Mon, Mar 10 2025, Miklos Szeredi wrote:

> On Fri, 7 Mar 2025 at 16:31, Luis Henriques <luis@xxxxxxxxxx> wrote:
>
>> Any further feedback on this patch, or is it already OK for being merged?
>
> The patch looks okay.  I have ideas about improving the name, but that can wait.

Naming suggestions are always welcome!

> What I think is still needed is an actual use case with performance numbers.

Well, the use-case I had in mind is, as I mentioned before, CVMFS.  I
think this file system could benefit from using this mechanism.

However, I don't think that measuring the direct benefits is something
easily done.  At the moment, it uses a thread that tries to drain the
cache using the FUSE_NOTIFY_INVAL_{INODE,ENTRY} operations.  These are,
obviously, operations that are much more expensive than the proposed
FUSE_NOTIFY_INC_EPOCH.  But, on the other hand, they have *immediate*
effect while the new operation does not: without the call to
shrink_dcache_sb() it's effect can only be observed in the long run.

I can try to come up with some artificial test case for this, but
comparing these operations will always need to be done indirectly.  And I
wonder how useful that would be.

>> And what about the extra call to shrink_dcache_sb(), do you think that
>> would that be acceptable?  Maybe that could be conditional, by for example
>> setting a flag.
>
> My wish would be a more generic "garbage collection" mechanism that
> would collect stale cache entries and get rid of them in the
> background.  Doing that synchronously doesn't really make sense, IMO.

So, you're proposing something like having a workqueue that would walk
through the entries.  And this workqueue would be triggered when the epoch
is increased.

> But that can be done independently of this patch, obviously.

OK, cool!  I'm adding this to my TODO list, I can have a look into it once
we're done this patch.

Cheers,
-- 
Luís