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?
