> On Aug 20, 2025, at 1:55 AM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > External email: Use caution opening links or attachments > > > On Wed, 20 Aug 2025 at 01:35, Jim Harris <jiharris@xxxxxxxxxx> wrote: > >> Can we safely depend on the FUSE_NOTIFY_INVAL_ENTRY notifications to trigger FORGET commands for the associated inodes? If not, can we consider adding a new FUSE_NOTIFY_DROP_ENTRY notification that would ask the kernel to release the inode and send a FORGET command when memory pressure or clean-up is needed by the device? > > As far as I understand what you want is drop the entry from the cache > *if it is unused*. Plain FUSE_NOTIFY_INVAL_ENTRY will unhash the > dentry regardless of its refcount, of course FORGET will be sent only > after the reference is released. > > FUSE_NOTIFY_INVAL_ENTRY with FUSE_EXPIRE_ONLY will do something like > your desired FUSE_NOTIFY_DROP_ENTRY operation, at least on virtiofs > (fc->delete_stale is on). I notice there's a fuse_dir_changed() call > regardless of FUSE_EXPIRE_ONLY, which is not appropriate for the drop > case, this can probably be moved inside the !FUSE_EXPIRE_ONLY branch. Thanks for the clarification. For that extra fuse_dir_changed() call - is this a required fix for correctness or just an optimization to avoid unnecessarily invalidating the parent directory’s attributes? > > The other question is whether something more efficient should be > added. E.g. FUSE_NOTIFY_SHRINK_LOOKUP_CACHE with a num_drop argument > that tells fuse to try to drop this many unused entries? Absolutely something like this would be more efficient. Using FUSE_NOTIFY_INVAL_ENTRY requires saving filenames which isn’t ideal. > Thanks, > Miklos
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
