I plan to try and use readahead_expand in Orangefs... -Mike On Tue, Feb 16, 2021 at 8:28 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > 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.
