On Thu, Mar 23, 2023 at 07:51:09AM -0700, Darrick J. Wong wrote: > On Thu, Mar 23, 2023 at 03:26:43AM +0000, Matthew Wilcox wrote: > > On Mon, Mar 06, 2023 at 02:40:55PM +0530, Ritesh Harjani wrote: > > > "Matthew Wilcox (Oracle)" <willy@xxxxxxxxxxxxx> writes: > > > > > > > Prepare ext4 to support large folios in the page writeback path. > > > > > > Sure. I am guessing for ext4 to completely support large folio > > > requires more work like fscrypt bounce page handling doesn't > > > yet support folios right? > > > > > > Could you please give a little background on what all would be required > > > to add large folio support in ext4 buffered I/O path? > > > (I mean ofcourse other than saying move ext4 to iomap ;)) > > > > > > What I was interested in was, what other components in particular for > > > e.g. fscrypt, fsverity, ext4's xyz component needs large folio support? > > > > > > And how should one go about in adding this support? So can we move > > > ext4's read path to have large folio support to get started? > > > Have you already identified what all is missing from this path to > > > convert it? > > > > Honestly, I don't know what else needs to be done beyond this patch > > series. I can point at some stuff and say "This doesn't work", but in > > general, you have to just enable it and see what breaks. A lot of the > > buffer_head code is not large-folio safe right now, so that's somewhere > > to go and look. Or maybe we "just" convert to iomap, and never bother > > fixing the bufferhead code for large folios. > > Yes. Let's leave bufferheads in the legacy doo-doo-dooooo basement > instead of wasting more time on them. Ideally we'd someday run all the > filesystems through: > > bufferheads -> iomap with bufferheads -> iomap with folios -> iomap with > large folios -> retire to somewhere cheaper than Hawaii Places cheaper than Hawaii probably aren't as pretty as Hawaii though :-( XFS is fine because it uses xfs_buf, but if we don't add support for large folios to bufferheads, we can't support LBA size > PAGE_SIZE even to read the superblock. Maybe that's fine ... only filesystems which don't use sb_bread() get to support LBA size > PAGE_SIZE. I really want to see a cheaper abstraction for accessing the block device than BHs. Or xfs_buf for that matter.
