> As I said, I can't really imagine use-cases for auto-punching holes
> in a file-based cache.
That's no reason to say there aren't any. I gave a few when I first suggested that fallocate() be used instead. Marking parts of files as volatile can help optimise large scale cache management (e.g. for HSMs, SSD file caches, squid, etc) - it's not a phone/desktop web browser cache that I'm thinking of here.
> Besides, filesystems would all need to be updated to support volatile
Just like the page cache needs to be updated to support it, eh? :)
Besides, this is just confusing implementation with API. The API needs to support it from the start as we can't change that over time. Filesystem implementation can be done later, as well as change over time, so we don't need to have that up front....
> And the existence of files whose data which might disappear at any point
> without anyone touching them seems a radical new feature for a
> filesystem, which seems to me like it could cause all sorts of problems.
When you use your filesystem as an access cache for some other data, this is exactly the expected behaviour. Only right now, the cache application causes files to disappear at random points in time. Volatile ranges on files just moves a common cache management mechanism into the filesystem so it can be done when the filesystem needs it to be done....