[PATCH 0/4] f2fs: Remove uses of writepage

[PATCH 0/4] f2fs: Remove uses of writepage

[Matthew Wilcox (Oracle)]

I was planning on sending this next cycle, but maybe there's time to
squeeze these patches into the upcoming merge window?

f2fs already implements writepages and migrate_folio for all three
address_space_operations, so either ->writepage will never be called (by
migration) or it will only be harmful (if called from pageout()).

The only remaining filesystem with ->writepage defined in next-20250307
is vboxsf, so the concept of removing ->writepage is well proven.  I
have some follow-up patches which simplify f2fs writeback afterwards,
but I think we can postpone them to next cycle.

See
https://lore.kernel.org/linux-fsdevel/20250307135414.2987755-1-willy@infradead.org/
for where we're going; the first four patches in that series are the
same as the four patches in this series, and I've split them out here
for your convenience.

Matthew Wilcox (Oracle) (4):
  f2fs: Remove check for ->writepage
  f2fs: Remove f2fs_write_data_page()
  f2fs: Remove f2fs_write_meta_page()
  f2fs: Remove f2fs_write_node_page()

 fs/f2fs/checkpoint.c |  7 -------
 fs/f2fs/data.c       | 28 ----------------------------
 fs/f2fs/node.c       |  8 --------
 3 files changed, 43 deletions(-)

-- 
2.47.2

[PATCH 1/4] f2fs: Remove check for ->writepage

[Matthew Wilcox (Oracle)]

We're almost able to remove a_ops->writepage.  This check is unnecessary
as we'll never call into __f2fs_write_data_pages() for character
devices.

Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
---
 fs/f2fs/data.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index c82d949709f4..a80d5ef9acbb 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -3280,10 +3280,6 @@ static int __f2fs_write_data_pages(struct address_space *mapping,
 	int ret;
 	bool locked = false;
 
-	/* deal with chardevs and other special file */
-	if (!mapping->a_ops->writepage)
-		return 0;
-
 	/* skip writing if there is no dirty page in this inode */
 	if (!get_dirty_pages(inode) && wbc->sync_mode == WB_SYNC_NONE)
 		return 0;
-- 
2.47.2

[PATCH 2/4] f2fs: Remove f2fs_write_data_page()

[Matthew Wilcox (Oracle)]

Mappings which implement writepages should not implement writepage
as it can only harm writeback patterns.

Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
---
 fs/f2fs/data.c | 24 ------------------------
 1 file changed, 24 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index a80d5ef9acbb..cdd63e8ad42e 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -2935,29 +2935,6 @@ int f2fs_write_single_data_page(struct folio *folio, int *submitted,
 	return err;
 }
 
-static int f2fs_write_data_page(struct page *page,
-					struct writeback_control *wbc)
-{
-	struct folio *folio = page_folio(page);
-#ifdef CONFIG_F2FS_FS_COMPRESSION
-	struct inode *inode = folio->mapping->host;
-
-	if (unlikely(f2fs_cp_error(F2FS_I_SB(inode))))
-		goto out;
-
-	if (f2fs_compressed_file(inode)) {
-		if (f2fs_is_compressed_cluster(inode, folio->index)) {
-			folio_redirty_for_writepage(wbc, folio);
-			return AOP_WRITEPAGE_ACTIVATE;
-		}
-	}
-out:
-#endif
-
-	return f2fs_write_single_data_page(folio, NULL, NULL, NULL,
-						wbc, FS_DATA_IO, 0, true);
-}
-
 /*
  * This function was copied from write_cache_pages from mm/page-writeback.c.
  * The major change is making write step of cold data page separately from
@@ -4111,7 +4088,6 @@ static void f2fs_swap_deactivate(struct file *file)
 const struct address_space_operations f2fs_dblock_aops = {
 	.read_folio	= f2fs_read_data_folio,
 	.readahead	= f2fs_readahead,
-	.writepage	= f2fs_write_data_page,
 	.writepages	= f2fs_write_data_pages,
 	.write_begin	= f2fs_write_begin,
 	.write_end	= f2fs_write_end,
-- 
2.47.2

[PATCH 3/4] f2fs: Remove f2fs_write_meta_page()

[Matthew Wilcox (Oracle)]

Mappings which implement writepages should not implement writepage
as it can only harm writeback patterns.

Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
---
 fs/f2fs/checkpoint.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index a35595f8d3f5..412282f50cbb 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -381,12 +381,6 @@ static int __f2fs_write_meta_page(struct page *page,
 	return AOP_WRITEPAGE_ACTIVATE;
 }
 
-static int f2fs_write_meta_page(struct page *page,
-				struct writeback_control *wbc)
-{
-	return __f2fs_write_meta_page(page, wbc, FS_META_IO);
-}
-
 static int f2fs_write_meta_pages(struct address_space *mapping,
 				struct writeback_control *wbc)
 {
@@ -507,7 +501,6 @@ static bool f2fs_dirty_meta_folio(struct address_space *mapping,
 }
 
 const struct address_space_operations f2fs_meta_aops = {
-	.writepage	= f2fs_write_meta_page,
 	.writepages	= f2fs_write_meta_pages,
 	.dirty_folio	= f2fs_dirty_meta_folio,
 	.invalidate_folio = f2fs_invalidate_folio,
-- 
2.47.2

[PATCH 4/4] f2fs: Remove f2fs_write_node_page()

[Matthew Wilcox (Oracle)]

Mappings which implement writepages should not implement writepage
as it can only harm writeback patterns.

Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
---
 fs/f2fs/node.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 36614a1c2590..b78c1f95bc04 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1784,13 +1784,6 @@ int f2fs_move_node_page(struct page *node_page, int gc_type)
 	return err;
 }
 
-static int f2fs_write_node_page(struct page *page,
-				struct writeback_control *wbc)
-{
-	return __write_node_page(page, false, NULL, wbc, false,
-						FS_NODE_IO, NULL);
-}
-
 int f2fs_fsync_node_pages(struct f2fs_sb_info *sbi, struct inode *inode,
 			struct writeback_control *wbc, bool atomic,
 			unsigned int *seq_id)
@@ -2217,7 +2210,6 @@ static bool f2fs_dirty_node_folio(struct address_space *mapping,
  * Structure of the f2fs node operations
  */
 const struct address_space_operations f2fs_node_aops = {
-	.writepage	= f2fs_write_node_page,
 	.writepages	= f2fs_write_node_pages,
 	.dirty_folio	= f2fs_dirty_node_folio,
 	.invalidate_folio = f2fs_invalidate_folio,
-- 
2.47.2

Re: [PATCH 0/4] f2fs: Remove uses of writepage

[Jaegeuk Kim]

On 03/07, Matthew Wilcox (Oracle) wrote:
> I was planning on sending this next cycle, but maybe there's time to
> squeeze these patches into the upcoming merge window?
> 
> f2fs already implements writepages and migrate_folio for all three
> address_space_operations, so either ->writepage will never be called (by
> migration) or it will only be harmful (if called from pageout()).

My tree sitting on [1] doesn't have mm-next, which looks difficult to test this
series for test alone. Matthew, can you point which patches I need to apply
in mm along with this for test?

[1] f286757b644c "Merge tag 'timers-urgent-2025-02-03' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip"


> 
> The only remaining filesystem with ->writepage defined in next-20250307
> is vboxsf, so the concept of removing ->writepage is well proven.  I
> have some follow-up patches which simplify f2fs writeback afterwards,
> but I think we can postpone them to next cycle.
> 
> See
> https://lore.kernel.org/linux-fsdevel/20250307135414.2987755-1-willy@infradead.org/
> for where we're going; the first four patches in that series are the
> same as the four patches in this series, and I've split them out here
> for your convenience.
> 
> Matthew Wilcox (Oracle) (4):
>   f2fs: Remove check for ->writepage
>   f2fs: Remove f2fs_write_data_page()
>   f2fs: Remove f2fs_write_meta_page()
>   f2fs: Remove f2fs_write_node_page()
> 
>  fs/f2fs/checkpoint.c |  7 -------
>  fs/f2fs/data.c       | 28 ----------------------------
>  fs/f2fs/node.c       |  8 --------
>  3 files changed, 43 deletions(-)
> 
> -- 
> 2.47.2

Re: [PATCH 0/4] f2fs: Remove uses of writepage

[Matthew Wilcox]

On Fri, Mar 07, 2025 at 08:39:56PM +0000, Jaegeuk Kim wrote:
> On 03/07, Matthew Wilcox (Oracle) wrote:
> > I was planning on sending this next cycle, but maybe there's time to
> > squeeze these patches into the upcoming merge window?
> > 
> > f2fs already implements writepages and migrate_folio for all three
> > address_space_operations, so either ->writepage will never be called (by
> > migration) or it will only be harmful (if called from pageout()).
> 
> My tree sitting on [1] doesn't have mm-next, which looks difficult to test this
> series for test alone. Matthew, can you point which patches I need to apply
> in mm along with this for test?
> 
> [1] f286757b644c "Merge tag 'timers-urgent-2025-02-03' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip"

Oh, you don't need any extra patches.  The ->writepage removal has been
going on since mid-2021 (commit 21b4ee7029c9 was the first removal, I
believe).

Re: [PATCH 0/4] f2fs: Remove uses of writepage

[Jaegeuk Kim]

On 03/07, Matthew Wilcox wrote:
> On Fri, Mar 07, 2025 at 08:39:56PM +0000, Jaegeuk Kim wrote:
> > On 03/07, Matthew Wilcox (Oracle) wrote:
> > > I was planning on sending this next cycle, but maybe there's time to
> > > squeeze these patches into the upcoming merge window?
> > > 
> > > f2fs already implements writepages and migrate_folio for all three
> > > address_space_operations, so either ->writepage will never be called (by
> > > migration) or it will only be harmful (if called from pageout()).
> > 
> > My tree sitting on [1] doesn't have mm-next, which looks difficult to test this
> > series for test alone. Matthew, can you point which patches I need to apply
> > in mm along with this for test?
> > 
> > [1] f286757b644c "Merge tag 'timers-urgent-2025-02-03' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip"
> 
> Oh, you don't need any extra patches.  The ->writepage removal has been
> going on since mid-2021 (commit 21b4ee7029c9 was the first removal, I
> believe).

Ah, I see. Thank you for the confirmation. Let me apply them and test a quick.

Re: [PATCH 1/4] f2fs: Remove check for ->writepage

[Chao Yu]

On 3/8/25 02:21, Matthew Wilcox (Oracle) wrote:
> We're almost able to remove a_ops->writepage.  This check is unnecessary
> as we'll never call into __f2fs_write_data_pages() for character
> devices.
> 
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>

Reviewed-by: Chao Yu <chao@kernel.org>

Thanks,

Re: [PATCH 2/4] f2fs: Remove f2fs_write_data_page()

[Chao Yu]

On 3/8/25 02:21, Matthew Wilcox (Oracle) wrote:
> Mappings which implement writepages should not implement writepage
> as it can only harm writeback patterns.
> 
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>

Reviewed-by: Chao Yu <chao@kernel.org>

Thanks,

Re: [PATCH 3/4] f2fs: Remove f2fs_write_meta_page()

[Chao Yu]

On 3/8/25 02:21, Matthew Wilcox (Oracle) wrote:
> Mappings which implement writepages should not implement writepage
> as it can only harm writeback patterns.
> 
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>

Reviewed-by: Chao Yu <chao@kernel.org>

Thanks,

Re: [PATCH 4/4] f2fs: Remove f2fs_write_node_page()

[Chao Yu]

On 3/8/25 02:21, Matthew Wilcox (Oracle) wrote:
> Mappings which implement writepages should not implement writepage
> as it can only harm writeback patterns.
> 
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>

Reviewed-by: Chao Yu <chao@kernel.org>

Thanks,

Re: [f2fs-dev] [PATCH 0/4] f2fs: Remove uses of writepage

[patchwork-bot+f2fs]

Hello:

This series was applied to jaegeuk/f2fs.git (dev)
by Jaegeuk Kim <jaegeuk@kernel.org>:

On Fri,  7 Mar 2025 18:21:46 +0000 you wrote:
> I was planning on sending this next cycle, but maybe there's time to
> squeeze these patches into the upcoming merge window?
> 
> f2fs already implements writepages and migrate_folio for all three
> address_space_operations, so either ->writepage will never be called (by
> migration) or it will only be harmful (if called from pageout()).
> 
> [...]

Here is the summary with links:
  - [f2fs-dev,1/4] f2fs: Remove check for ->writepage
    https://git.kernel.org/jaegeuk/f2fs/c/448a834f89ad
  - [f2fs-dev,2/4] f2fs: Remove f2fs_write_data_page()
    https://git.kernel.org/jaegeuk/f2fs/c/6ad3ddbee892
  - [f2fs-dev,3/4] f2fs: Remove f2fs_write_meta_page()
    https://git.kernel.org/jaegeuk/f2fs/c/3b47398d9861
  - [f2fs-dev,4/4] f2fs: Remove f2fs_write_node_page()
    https://git.kernel.org/jaegeuk/f2fs/c/7ff0104a8052

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [f2fs-dev] [PATCH 0/4] f2fs: Remove uses of writepage

[Matthew Wilcox]

On Tue, Mar 11, 2025 at 07:50:38PM +0000, patchwork-bot+f2fs@kernel.org wrote:
> Hello:
> 
> This series was applied to jaegeuk/f2fs.git (dev)
> by Jaegeuk Kim <jaegeuk@kernel.org>:

Thanks!

FWIW, I have a tree with 75 patches in it on top of this that do more
folio conversion work.  It's not done yet; maybe another 200 patches to
go?  I don't think it's worth posting at this point in the cycle, so
I'll wait until -rc1 to post, by which point it'll probably be much
larger.

Re: [f2fs-dev] [PATCH 0/4] f2fs: Remove uses of writepage

[Jaegeuk Kim]

On 03/12, Matthew Wilcox wrote:
> On Tue, Mar 11, 2025 at 07:50:38PM +0000, patchwork-bot+f2fs@kernel.org wrote:
> > Hello:
> > 
> > This series was applied to jaegeuk/f2fs.git (dev)
> > by Jaegeuk Kim <jaegeuk@kernel.org>:
> 
> Thanks!
> 
> FWIW, I have a tree with 75 patches in it on top of this that do more
> folio conversion work.  It's not done yet; maybe another 200 patches to
> go?  I don't think it's worth posting at this point in the cycle, so
> I'll wait until -rc1 to post, by which point it'll probably be much
> larger.

Ok, thanks for the work! Will keep an eye on.

Re: [f2fs-dev] [PATCH 0/4] f2fs: Remove uses of writepage

[Matthew Wilcox]

On Wed, Mar 12, 2025 at 01:22:41AM +0000, Jaegeuk Kim wrote:
> On 03/12, Matthew Wilcox wrote:
> > On Tue, Mar 11, 2025 at 07:50:38PM +0000, patchwork-bot+f2fs@kernel.org wrote:
> > > Hello:
> > > 
> > > This series was applied to jaegeuk/f2fs.git (dev)
> > > by Jaegeuk Kim <jaegeuk@kernel.org>:
> > 
> > Thanks!
> > 
> > FWIW, I have a tree with 75 patches in it on top of this that do more
> > folio conversion work.  It's not done yet; maybe another 200 patches to
> > go?  I don't think it's worth posting at this point in the cycle, so
> > I'll wait until -rc1 to post, by which point it'll probably be much
> > larger.
> 
> Ok, thanks for the work! Will keep an eye on.

Unfortunately, I thnk I have to abandon this effort.  It's only going
to make supporting large folios harder (ie there would then need to be
an equivalently disruptive series adding support for large folios).

The fundamental problem is that f2fs has no concept of block size !=
PAGE_SIZE.  So if you create a filesystem on a 4kB PAGE_SIZE kernel,
you can't mount it on a 16kB PAGE_SIZE kernel.  An example:

int f2fs_recover_inline_xattr(struct inode *inode, struct page *page)
{
        struct f2fs_inode *ri;
        ipage = f2fs_get_node_page(F2FS_I_SB(inode), inode->i_ino);
        ri = F2FS_INODE(page);

so an inode number is an index into the filesystem in PAGE_SIZE units,
not in filesystem block size units.  Fixing this is a major effort, and
I lack the confidence in my abilities to do it without breaking anything.

As an outline of what needs to happen, I think that rather than passing
around so many struct page pointers, we should be passing around either
folio + offset, or we should be passing around struct f2fs_inode pointers.
My preference is for the latter.  We can always convert back to the
folio containing the inode if we need to (eg to mark it dirty) and it
adds some typesafety by ensuring that we're passing around pointers that
we believe belong to an inode and not, say, a struct page which happens
to contain a directory entry.

This is a monster task, I think.  I'm going to have to disable f2fs
from testing with split page/folio.  This is going to be a big problem
for Android.

Re: [f2fs-dev] [PATCH 0/4] f2fs: Remove uses of writepage

[Jaegeuk Kim]

On 03/14, Matthew Wilcox wrote:
> On Wed, Mar 12, 2025 at 01:22:41AM +0000, Jaegeuk Kim wrote:
> > On 03/12, Matthew Wilcox wrote:
> > > On Tue, Mar 11, 2025 at 07:50:38PM +0000, patchwork-bot+f2fs@kernel.org wrote:
> > > > Hello:
> > > > 
> > > > This series was applied to jaegeuk/f2fs.git (dev)
> > > > by Jaegeuk Kim <jaegeuk@kernel.org>:
> > > 
> > > Thanks!
> > > 
> > > FWIW, I have a tree with 75 patches in it on top of this that do more
> > > folio conversion work.  It's not done yet; maybe another 200 patches to
> > > go?  I don't think it's worth posting at this point in the cycle, so
> > > I'll wait until -rc1 to post, by which point it'll probably be much
> > > larger.
> > 
> > Ok, thanks for the work! Will keep an eye on.
> 
> Unfortunately, I thnk I have to abandon this effort.  It's only going
> to make supporting large folios harder (ie there would then need to be
> an equivalently disruptive series adding support for large folios).
> 
> The fundamental problem is that f2fs has no concept of block size !=
> PAGE_SIZE.  So if you create a filesystem on a 4kB PAGE_SIZE kernel,
> you can't mount it on a 16kB PAGE_SIZE kernel.  An example:
> 
> int f2fs_recover_inline_xattr(struct inode *inode, struct page *page)
> {
>         struct f2fs_inode *ri;
>         ipage = f2fs_get_node_page(F2FS_I_SB(inode), inode->i_ino);
>         ri = F2FS_INODE(page);
> 
> so an inode number is an index into the filesystem in PAGE_SIZE units,
> not in filesystem block size units.  Fixing this is a major effort, and
> I lack the confidence in my abilities to do it without breaking anything.
> 
> As an outline of what needs to happen, I think that rather than passing
> around so many struct page pointers, we should be passing around either
> folio + offset, or we should be passing around struct f2fs_inode pointers.
> My preference is for the latter.  We can always convert back to the
> folio containing the inode if we need to (eg to mark it dirty) and it
> adds some typesafety by ensuring that we're passing around pointers that
> we believe belong to an inode and not, say, a struct page which happens
> to contain a directory entry.
> 
> This is a monster task, I think.  I'm going to have to disable f2fs
> from testing with split page/folio.  This is going to be a big problem
> for Android.

I see. fyi; in Android, I'm thinking to run 16KB page kernel with 16KB format
natively to keep block_size = PAGE_SIZE. Wasn't large folio to support a set
of pages while keeping block_size = PAGE_SIZE?

Re: [f2fs-dev] [PATCH 0/4] f2fs: Remove uses of writepage

[Matthew Wilcox]

On Fri, Mar 14, 2025 at 09:38:15PM +0000, Jaegeuk Kim wrote:
> On 03/14, Matthew Wilcox wrote:
> > Unfortunately, I thnk I have to abandon this effort.  It's only going
> > to make supporting large folios harder (ie there would then need to be
> > an equivalently disruptive series adding support for large folios).
> > 
> > The fundamental problem is that f2fs has no concept of block size !=
> > PAGE_SIZE.  So if you create a filesystem on a 4kB PAGE_SIZE kernel,
> > you can't mount it on a 16kB PAGE_SIZE kernel.  An example:
> > 
> > int f2fs_recover_inline_xattr(struct inode *inode, struct page *page)
> > {
> >         struct f2fs_inode *ri;
> >         ipage = f2fs_get_node_page(F2FS_I_SB(inode), inode->i_ino);
> >         ri = F2FS_INODE(page);
> > 
> > so an inode number is an index into the filesystem in PAGE_SIZE units,
> > not in filesystem block size units.  Fixing this is a major effort, and
> > I lack the confidence in my abilities to do it without breaking anything.
> > 
> > As an outline of what needs to happen, I think that rather than passing
> > around so many struct page pointers, we should be passing around either
> > folio + offset, or we should be passing around struct f2fs_inode pointers.
> > My preference is for the latter.  We can always convert back to the
> > folio containing the inode if we need to (eg to mark it dirty) and it
> > adds some typesafety by ensuring that we're passing around pointers that
> > we believe belong to an inode and not, say, a struct page which happens
> > to contain a directory entry.
> > 
> > This is a monster task, I think.  I'm going to have to disable f2fs
> > from testing with split page/folio.  This is going to be a big problem
> > for Android.
> 
> I see. fyi; in Android, I'm thinking to run 16KB page kernel with 16KB format
> natively to keep block_size = PAGE_SIZE. Wasn't large folio to support a set
> of pages while keeping block_size = PAGE_SIZE?

Oh, I think I do see a possible argument for continuing this work.

If we have an f2fs filesystem with a 16kB block size, we can use order-0
folios with a 16kB PAGE_SIZE kernel, and if we want to mount it on a
kernel with a 4kB PAGE_SIZE kernel, then we can use order-2 folios to
do that.

Is that a useful improvement to f2fs?  It's not really the intent of
large folios; it's supposed to be used to support arbitrary order folios.
But we have all the pieces in place such that we could tell the page
cache min-order = max-order = 2.

Re: [f2fs-dev] [PATCH 0/4] f2fs: Remove uses of writepage

[Jaegeuk Kim]

On 03/26, Matthew Wilcox wrote:
> On Fri, Mar 14, 2025 at 09:38:15PM +0000, Jaegeuk Kim wrote:
> > On 03/14, Matthew Wilcox wrote:
> > > Unfortunately, I thnk I have to abandon this effort.  It's only going
> > > to make supporting large folios harder (ie there would then need to be
> > > an equivalently disruptive series adding support for large folios).
> > > 
> > > The fundamental problem is that f2fs has no concept of block size !=
> > > PAGE_SIZE.  So if you create a filesystem on a 4kB PAGE_SIZE kernel,
> > > you can't mount it on a 16kB PAGE_SIZE kernel.  An example:
> > > 
> > > int f2fs_recover_inline_xattr(struct inode *inode, struct page *page)
> > > {
> > >         struct f2fs_inode *ri;
> > >         ipage = f2fs_get_node_page(F2FS_I_SB(inode), inode->i_ino);
> > >         ri = F2FS_INODE(page);
> > > 
> > > so an inode number is an index into the filesystem in PAGE_SIZE units,
> > > not in filesystem block size units.  Fixing this is a major effort, and
> > > I lack the confidence in my abilities to do it without breaking anything.
> > > 
> > > As an outline of what needs to happen, I think that rather than passing
> > > around so many struct page pointers, we should be passing around either
> > > folio + offset, or we should be passing around struct f2fs_inode pointers.
> > > My preference is for the latter.  We can always convert back to the
> > > folio containing the inode if we need to (eg to mark it dirty) and it
> > > adds some typesafety by ensuring that we're passing around pointers that
> > > we believe belong to an inode and not, say, a struct page which happens
> > > to contain a directory entry.
> > > 
> > > This is a monster task, I think.  I'm going to have to disable f2fs
> > > from testing with split page/folio.  This is going to be a big problem
> > > for Android.
> > 
> > I see. fyi; in Android, I'm thinking to run 16KB page kernel with 16KB format
> > natively to keep block_size = PAGE_SIZE. Wasn't large folio to support a set
> > of pages while keeping block_size = PAGE_SIZE?
> 
> Oh, I think I do see a possible argument for continuing this work.
> 
> If we have an f2fs filesystem with a 16kB block size, we can use order-0
> folios with a 16kB PAGE_SIZE kernel, and if we want to mount it on a
> kernel with a 4kB PAGE_SIZE kernel, then we can use order-2 folios to
> do that.
> 
> Is that a useful improvement to f2fs?  It's not really the intent of
> large folios; it's supposed to be used to support arbitrary order folios.
> But we have all the pieces in place such that we could tell the page
> cache min-order = max-order = 2.

It may be helpful in case where someone wants to try 4KB page kernel back,
after Android ships 16KB page/block products. Does it require a big surgery?