On Wed, Jan 24, 2024 at 03:57:39PM +1030, Qu Wenruo wrote: > > > On 2024/1/24 15:18, Matthew Wilcox wrote: > > On Wed, Jan 24, 2024 at 02:33:22PM +1030, Qu Wenruo wrote: > > > I'm pretty sure we would have some filesystems go utilizing larger folios to > > > implement their multi-page block size support. > > > > > > Thus in that case, can we have an interface change to make all folio > > > versions of filemap_*() to accept a file offset instead of page index? > > > > You're confused. There's no change needed to the filemap API to support > > large folios used by large block sizes. Quite possibly more of btrfs > > is confused, but it's really very simple. index == pos / PAGE_SIZE. > > That's all. Even if you have a 64kB block size device on a 4kB PAGE_SIZE > > machine. > > Yes, I understand that filemap API is always working on PAGE_SHIFTed index. OK, good. > The concern is, (hopefully) with more fses going to utilized large > folios, there would be two shifts. > > One folio shift (ilog2(blocksize)), one PAGE_SHIFT for filemap interfaces. Don't shift the file position by the folio_shift(). You want to support large(r) folios _and_ large blocksizes at the same time. ie 64kB might be the block size, but all that would mean would be that folio_shift() would be at least 16. It might be 17, 18 or 21 (for a THP). Filesystems already have to deal with different PAGE_SIZE, SECTOR_SIZE, fsblock size and LBA size. Folios aren't making things any worse here (they're also not making anything better in this area, but I never claimed they would). btrfs is slightly unusual in that it defined PAGE_SIZE and fsblock size to be the same (and then had to deal with the consequences of arm64/x86 interoperability later). But most filesystems have pretty good separation of the four concepts.
