Re: [LSF/MM/BPF TOPIC] Filesystem inode reclaim

[Andreas Dilger <adilger@dilger.ca>]

> On Apr 10, 2026, at 14:56, Jan Kara <jack@suse.cz> wrote:
> 
> On Fri 10-04-26 00:19:43, Christoph Hellwig wrote:
>> I think a patch is more useful than a discussion here, that idea has been
>> voiced multiple times, and effecticely implemented in XFS.
> 
> I know but after thinking for some time I wanted to get some feedback
> before I start coding.
> 
>> Trying to lift the XFS logic into the VFS and finding other consumers
>> for it would be very helpful.
> 
> I hope not to get all the complexity of XFS but we'll see :)
> 
>>> 1) Filesystems will be required to mark inodes that have non-trivial
>>> cleanup work to do on reclaim with an inode flag I_RECLAIM_HARD (or
>>> whatever :)). Usually I expect this to happen on first inode modification
>>> or so. This will require some per-fs work but it shouldn't be that
>>> difficult and filesystems can be adapted one-by-one as they decide to
>>> address these warnings from reclaim.
>> 
>> I think otherwise we call this dirty :)
> 
> Yup :) I was considering for a while to use another kind of dirty flag for
> this and then clean it from flush worker but in the end I decided against
> it as it would be IMHO confusing.
> 
>>> There's also a simpler approach to this problem but with more radical
>>> changes to behavior. For example getting rid of inode LRU completely -
>>> inodes without dentries referencing them anymore should be rare and it
>>> isn't very useful to cache them. So we can always drop inodes on last
>>> iput() (as we currently do for example for unlinked inodes). But I have a
>>> nagging feeling that somebody is depending on inode LRU somewhere - I'd
>>> like poll the collective knowledge of what could possibly go wrong here :)
>> 
>> I've heard this theory multiple times, but we really need to valide that
>> we don't need the LRU.  It also doesn't really solve the above problem,
>> as we still would not want to perform the expensive inode inactivation
>> work inline with the last dput.
>> 
>> So while this might be worth investigating, please keept it separate.
> 
> Ack. With the point Jeff made about NFS revalidations I agree it won't be
> straightforward.

Can this be opt-in to flag an inode with `I_KEEP_UNREFERENCED` so that it
is not reaped immediately when NFS does iput() on an inode (or even set
it on iget() by NFS for that matter, in case there are multiple users?
And a sysfs parameter that makes this optional for other filesystems
(defaults to off)?

That way you could float a trial balloon of an LRU-less kernel, but leave
an escape hatch/debug mechanism if this turns out to kill some workloads.
It would take some time (a few years) to get feedback, but this and the
negative dcache growth have also been discussed for that long without
forward progress.  Having a runtime parameter with the intent to make it
permanent in the future at least moves the needle.

Cheers, Andreas