Follow up to #1170 . Thank you for the clarifications on logic -- great to know that both last_access attribute it stored!

In our use case (https://github.com/con/fscacher/) size though is not an issue -- it is just a sheer number of files, and thus inodes consumed. I made a mistake to use "good old" EXT4 for HOME partition instead of BTRFS as for the main bulk storage and now I am paying the price of "running out of space" while still having GBs of actual space available. There is virtually no rule of thumb for what size (in bytes) we should aim for in our use case. But it might be feasible to figure out how many cached items to keep (also the information which is available since you know the number of cached items) and/or even better -- for how long (known since last_access is stored). I would have then set in our case cache to not exceed 10k entries and be no older than 1 week or so.

Do you think such modes of cleanup could be added to reduce_size call? (due to
(FWIW: unless reduce_size is to be triggered automagically, I see no reason for bytes_limit or any of those settings actually to be listed in the constructor, and not just to become arguments for reduce_size call).