> Doing this all in memory seems too complex. Probably I'm missing
> something, but why not do it with files?
That's the thing - it is doing this with files. People are focussing on memory/page cache behaviour because the initial target was tmpfs files.
> The concept could even be extended to disks, with files that are
> automatically removed by the kernel if the free space on the file
> system goes below certain threshold.
It already does that, through using the hole punching interface.
Indeed, this is exactly the reason I originally suggested it needs to be fallocate() based. There are good reasons for allowing the filesystem to track volatile ranges to allow discards to be done when the filesystem reaches ENOSPC thresholds. Once again, the focus on tmpfs has tended to make people think purely of "this is only for page cache pages" and that ignores the wider usefulness it has for disk based caching applications.