Re: [PATCH v8] fuse: add more control over cache invalidation behaviour
From: Luis Henriques
Date: Thu Mar 13 2025 - 07:25:36 EST
On Thu, Mar 13 2025, Miklos Szeredi wrote:
> On Tue, 11 Mar 2025 at 12:08, Luis Henriques <luis@xxxxxxxxxx> 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