On Thu, Apr 20, 2023 at 08:03:55AM -0700, Darrick J. Wong wrote: > On Thu, Apr 20, 2023 at 02:28:36PM +0200, Pankaj Raghav wrote: > > On 2023-04-20 14:19, Hannes Reinecke wrote: > > >> > > >> **Questions on the future work**: > > >> > > >> As willy pointed out, we have to do this `order = mapping->host->i_blkbits - PAGE_SHIFT` in > > >> many places. Should we pursue something that willy suggested: encapsulating order in the > > >> mapping->flags as a next step?[1] > > >> > > >> > > >> [1] https://lore.kernel.org/lkml/ZDty+PQfHkrGBojn@xxxxxxxxxxxxxxxxxxxx/ > > I wouldn't mind XFS gaining a means to control folio sizes, personally. > At least that would make it easier to explore things like copy on write > with large weird file allocation unit sizes (2MB, 28k, etc). [random historical musings follow] Ah, how things go full circle. This is how XFS originally worked on Irix - it had read and write IO sizes that it used to control the size of buffers allocated ifor caching data in the per-inode chunk cache. That stuff was in the original port to Linux, we even had a mount option to allow users to determine preferred IO sizes (biosize) but that was removed in 2019 ago because it hadn't done anything for more than a decade. That was done around the same time the mp->m_readio_blocks and mp->m_writeio_blocks variables that it originally influenced were removed. Extent allocation sizes are still influenced this way by the allocsize mount option and m_writeio_blocks was renamed m_allocsize_blocks to keep this functionality for extent allocation... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
