When converting a filesystem from operating on pages to folios, there is a choice to be made, which is whether to attempt to support large folios as part of the same conversion, or just note that no attempt has been made (and mark the places accordingly).

It is beneficial to convert any filesystem from operating on pages to operating on folios for several reasons:

 * There are a lot of hidden calls to {{{compound_head()}}} buried inside macros and functions that take a struct page.  We can save kilobytes of kernel text (perhaps 1% of any individual filesystem) by doing the conversion.  It's not huge, but it's not nothing either in terms of CPU instruction cache.
 * The VFS now largely works in terms of folios instead of pages.  Once we've converted all the filesystems, we can delete all the conversion functions.
 * Once we've got rid of all the calls to {{{page->mapping}}}, we can remove {{{->mapping}}} from {{{struct page}}} (leaving it only in {{{struct folio}}}) and stop poisoning all the tail page {{{->mapping}}} members.
 * There are other cleanups which depend on this happening, but they're of less interest to filesystem authors.

But why should a filesystem put in the effort to support large folios (aka multi-page folios)?

 * Lower overheads
   * Fewer calls to the page allocator
   * Shorter LRU list helps vmscan age memory
   * Fewer calls to the page cache for large read()/write()
   * Fewer calls to the architecture code for handling faults in mmaped files
   * Potential use of larger TLB entries (eg contPTE / NAPOT)
 * Being a better kernel citizen
   * The more code using large folios, the easier it is to allocate large folios
 * Support for LBA size > PAGE_SIZE

The costs may outweigh the benefits.  I would not invest time in making iso9660, adfs or efs support large folios.  But for filesystems which are used every day (XFS, NFS, ext4, btrfs, ...) the benefit is very much worth the cost.