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
