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

[Luis Henriques <luis@igalia.com>]

On Thu, Mar 13 2025, Miklos Szeredi wrote:

> On Tue, 11 Mar 2025 at 12:08, Luis Henriques <luis@igalia.com> wrote:
>
>> 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.
>
> We need more than just a hunch that this will work.  Having code out
> there that actually uses the new feature is a hard requirement.
>
> It does not need to be actually committed to the cvmfs repo, but some
> indication that the code will be accepted by the maintainers once the
> kernel part is upstream is needed.

OK, makes sense.  I do have a local cvmfs patch to use this new
notification.  For now it's just a hack to replace the current code.  It
has to be cleaned-up so that it uses FUSE_NOTIFY_INC_EPOCH only when it's
available in libfuse.  My plan was to do this only after the kernel patch
was merged, but I can try to share an earlier version of it.

>> 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.
>
> How so?  Isn't the advantage of FUSE_NOTIFY_INC_EPOCH that it spares
> the server of having to send out FUSE_NOTIFY_INVAL_ENTRY for *all* of
> the currently looked up dentries?

Well, I guess I misunderstood you.  I can use my hacked cvmfs to measure
the improvement of removing this loop and replace it with a single
FUSE_NOTIFY_INC_EPOCH.  Obviously, the performance improvements will
depend on how many dentries were cached.

>> 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.
>
> Any test is better than no test.
>
>> 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.
>
> Not just.  Also should periodically clean up expired dentries.

Hmmm... And would you like this to be done in fuse?  Or do you expect this
to me a more generic mechanism in dcache, available for other filesystems
as well?

Cheers,
-- 
Luís