On Tue, Feb 16, 2021 at 11:32:15AM +0100, Christoph Hellwig wrote: > On Mon, Feb 15, 2021 at 03:44:52PM +0000, David Howells wrote: > > Provide a function, readahead_expand(), that expands the set of pages > > specified by a readahead_control object to encompass a revised area with a > > proposed size and length. > > > > The proposed area must include all of the old area and may be expanded yet > > more by this function so that the edges align on (transparent huge) page > > boundaries as allocated. > > > > The expansion will be cut short if a page already exists in either of the > > areas being expanded into. Note that any expansion made in such a case is > > not rolled back. > > > > This will be used by fscache so that reads can be expanded to cache granule > > boundaries, thereby allowing whole granules to be stored in the cache, but > > there are other potential users also. > > So looking at linux-next this seems to have a user, but that user is > dead wood given that nothing implements ->expand_readahead. > > Looking at the code structure I think netfs_readahead and > netfs_rreq_expand is a complete mess and needs to be turned upside > down, that is instead of calling back from netfs_readahead to the > calling file system, split it into a few helpers called by the > caller. That's funny, we modelled it after iomap. > But even after this can't we just expose the cache granule boundary > to the VM so that the read-ahead request gets setup correctly from > the very beginning? The intent is that this be usable by filesystems which want to (for example) compress variable sized blocks. So they won't know which pages they want to readahead until they're in their iomap actor routine, see that the extent they're in is compressed, and find out how large the extent is.
