VFS caching of file extents

[Matthew Wilcox <willy@infradead.org>]

Today it is the responsibility of each filesystem to maintain the mapping
from file logical addresses to disk blocks (*).  There are various ways
to query that information, eg calling get_block() or using iomap.

What if we pull that information up into the VFS?  Filesystems obviously
_control_ that information, so need to be able to invalidate entries.
And we wouldn't want to store all extents in the VFS all the time, so
would need to have a way to call into the filesystem to populate ranges
of files.  We'd need to decide how to lock/protect that information
-- a per-file lock?  A per-extent lock?  No locking, just a seqcount?
We need a COW bit in the extent which tells the user that this extent
is fine for reading through, but if there's a write to be done then the
filesystem needs to be asked to create a new extent.

There are a few problems I think this can solve.  One is efficient
implementation of NFS READPLUS.  Another is the callback from iomap
to the filesystem when doing buffered writeback.  A third is having a
common implementation of FIEMAP.  I've heard rumours that FUSE would like
something like this, and maybe there are other users that would crop up.

Anyway, this is as far as my thinking has got on this topic for now.
Maybe there's a good idea here, maybe it's all a huge overengineered mess
waiting to happen.  I'm sure other people know this area of filesystems
better than I do.

(*) For block device filesystems.  Obviously network filesystems and
synthetic filesystems don't care and can stop reading now.  Umm, unless
maybe they _want_ to use it, eg maybe there's a sharded thing going on and
the fs wants to store information about each shard in the extent cache?