Re: [PATCH v6 2/2] fuse: add new function to invalidate cache for all inodes

[Dave Chinner <david@fromorbit.com>]

On Mon, Feb 17, 2025 at 01:32:28PM +0000, Luis Henriques wrote:
> Currently userspace is able to notify the kernel to invalidate the cache
> for an inode.  This means that, if all the inodes in a filesystem need to
> be invalidated, then userspace needs to iterate through all of them and do
> this kernel notification separately.
> 
> This patch adds a new option that allows userspace to invalidate all the
> inodes with a single notification operation.  In addition to invalidate
> all the inodes, it also shrinks the sb dcache.

You still haven't justified why we should be exposing this
functionality in a low level filesystem ioctl out of sight of the
VFS.

User driven VFS cache invalidation has long been considered a
DOS-in-waiting, hence we don't allow user APIs to invalidate caches
like this. This is one of the reasons that /proc/sys/vm/drop_caches
requires root access - it's system debug and problem triage
functionality, not a production system interface....

Every other situation where filesystems invalidate vfs caches is
during mount, remount or unmount operations.  Without actually
explaining how this functionality is controlled and how user abuse
is not possible (e.g. explain the permission model and/or how only
root can run this operation), it is not really possible to determine
whether we should unconditional allow VFS cache invalidation outside
of the existing operation scope....

FInally, given that the VFS can only do best-effort invalidation
and won't provide FUSE (or any other filesystem) with any cache
invalidation guarantees outside of specific mount and unmount
contexts, I'm not convinced that this is actually worth anything...

-Dave.
-- 
Dave Chinner
david@fromorbit.com