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

Jan Kara
2026-04-13T07:46:01Z

On Fri 10-04-26 15:14:04, Andreas Dilger wrote:
> > 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.

Thanks for an interesting idea! But from VFS point of view this won't bring
much as we'll have to keep the complexity of inode LRU and the associated
inode cleanup woes anyway. It still could be interesting from MM point of
view as in most cases FS caches would be faster to reclaim on memory
pressure. Anyway this is sufficiently complex that I don't want to
complicate the "let's fix inode reclaim warnings" series with this...

Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR