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

[Miklos Szeredi]

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.

> 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?

> 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.

Thanks,
Miklos