Re: [LSF/MM/BPF TOPIC] Changing reference counting rules for inodes

[Matthew Wilcox <willy@infradead.org>]

On Mon, Mar 03, 2025 at 12:00:29PM -0500, Josef Bacik wrote:
> I've recently gotten annoyed with the current reference counting rules that
> exist in the file system arena, specifically this pattern of having 0 referenced
> objects that indicate that they're ready to be reclaimed.
> 
> We do this everywhere, with inodes, dentries, and folios, but I specifically

Folios?  I don't think so.  The only exceptions I know to the rule of
"when a folio refcount reaches 0 it is reclaimed" are:

 - Frozen folios.  Filesystems should never see a frozen folio.
 - Devmem folios.  They were freed when their refcount reached 1.
   Alistair has that fixed in -next

If there's something you don't like about the folio refcount, please let
me know.  I have Some Thoughts:

 - It's silly that the pagecache takes 2^order references on the folio.
   It should be just 1
 - We play with the refcount in too many places.  In conjunction with
   the first point, what I'd like is if filemap_add_folio() consumed the
   refcount on the folio passed to it.  That is, today we allocate the
   folio (refcount 1), pass it to filemap_add_folio() which increments
   the refcount by 2^n and then put the refcount in readahead_folio().
   We should do noe of that; just have the pagecacahe assume the
   refcount that was passed in.  There are a few filesystems this would
   break today ... need to finish some more conversions.

Anyway, what's your problem with the folio refcount?  Filesystems
shouldn't need to care about folio refcounts (other than fuse which
decided to get all up in the mm's business).