From: Nanzhe Zhao <nzzhao.sigma@gmail.com>
To: linux-f2fs-devel@lists.sourceforge.net,
Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <chao@kernel.org>
Cc: Barry Song <baohua@kernel.org>, Juan Yescas <jyescas@google.com>,
Daeho Jeong <daehojeong@google.com>,
linux-kernel@vger.kernel.org, Dev Jain <Dev.Jain@arm.com>,
David Hildenbrand <David.Hildenbrand@arm.com>,
Pengfei Li <lipengfei28@xiaomi.com>,
Bo Zhang <zhangbo56@xiaomi.com>,
Kalesh Singh <kaleshsingh@google.com>,
Nanzhe Zhao <nzzhao@126.com>, Nanzhe Zhao <zhaonanzhe@xiaomi.com>,
Ryan Roberts <Ryan.Roberts@arm.com>
Subject: [f2fs-dev] [PATCH v8 00/15] f2fs: support & optimize large folios for writable files
Date: Wed, 28 Oct 2026 23:43:51 +0800 [thread overview]
Message-ID: <20261028154407.1601430-1-nzzhao.sigma@gmail.com> (raw)
From: Nanzhe Zhao <zhaonanzhe@xiaomi.com>
This series supports large folios for most readable/writable files
in buffered I/O paths, including normal files, block-layer encrypted
files, and atomic files except for inline-data files, compressed files,
and quota files.
It also extends f2fs_folio_state to coexist with f2fs page-private
flags and to handle large folio write path and partial truncate of
large folios correctly. A valid large folio always carries a
f2fs_folio_state at its folio->private in the current implementation.
Benchmark details can be found in the RFC v2 cover letter:
https://lore.kernel.org/r/20260622160830.324455-1-zhaonanzhe@xiaomi.com
Changes in v8:
- 01/15: add a sanity check in f2fs_folio_has_ffs(): if a large folio
carries non-pointer private data (PAGE_PRIVATE_NOT_POINTER), report
it with f2fs_bug_on() and return false instead of casting the value
to a struct f2fs_folio_state pointer.
- 03/15: cache sbi before dropping read_pages_pending, so
f2fs_finish_read_bio() no longer uses F2FS_F_SB(folio) after a sync
reader has been woken up and may have released the folio.
- 05/15: clear the dirty bits of the whole folio on success, otherwise
post-EOF subpages (e.g. fill_zero() with FALLOC_FL_KEEP_SIZE, or a
block migration beyond EOF) keep the folio redirtied forever;
- recheck cp_error after f2fs_balance_fs() or the trylock_op() backoff
dropped the folio lock, and drop the folio instead of writing on a
filesystem which can no longer checkpoint;
- reset the per-folio submitted counter for each dirty range.
- 07/15: since the whole valid range below will be marked dirty, a large
folio whose subpage was invalidated by a racing collapse/insert/punch
hole is not usable; after folio_lock(), unlock it and return
VM_FAULT_NOPAGE (-EFAULT) so the faulting access is retried instead
of dirtying the stale subpages.
- 08/15: keep PAGE_PRIVATE_GCING on a failed GC write which redirties
the folio, and clear it only when no dirty subpage is left; mark the
target subpage dirty in f2fs_defragment_range() and
f2fs_migrate_blocks(); and submit the cached bio before unlocking a
large folio in move_data_page() to avoid an AB-BA deadlock with
WB_SYNC_ALL.
- 15/15: make redirty_blocks() large-folio aware: allocate the
f2fs_folio_state and mark the cluster range dirty. This is mainly
for the chattr +c (FS_IOC_SETFLAGS) case, where the compression flag
is set on an inode that keeps using large folios until it is evicted;
since F2FS_IOC_COMPRESS_FILE is already rejected for large-folio
mappings, this hint state is only reachable through chattr +c.
Without this, F2FS_IOC_DECOMPRESS_FILE and
F2FS_IOC_RELEASE_COMPRESS_BLOCKS would find no dirty range and
silently skip the rewrite.
Many thanks to Chao for the detailed v7 review; several of the fixes
above are folded in from his suggestions.
Changes in v7:
- 01/15: realloc the f2fs_folio_state in f2fs_get_lock_data_folio() if
it was released while the folio was unlocked.
- 04/15: on an atomic buffered write repeat if folio was unlocked, check the
COW block before reserving it again, so inc_atomic_write_cnt() is not called twice.
- 08/15: clear PAGE_PRIVATE_GCING if large folio has no dirty sub pages
when f2fs_trylock_op() fails before any write is submitted in f2fs_do_write_data_page().
No other functional changes.
Changes in v6:
- Rebased onto the f2fs dev branch (fd106ada4dee).
- v5 12/16 ("f2fs: wait for folio writeback before ffs_detach_free")
is dropped, because the lkp warning reported by [1] was caused by a
write_pages_pending leak on the GC truncate path.
- Improve large-folio support in the f2fs_do_write_data_page() path used
by GC:
- 05/15: use __folio_start_writeback(folio, folio_test_dirty(folio))
in both the IPU and OPU paths, so a single-subpage GC write does not
clear PAGECACHE_TAG_TOWRITE while other subpages are still dirty [3].
- 05/15: add f2fs_ffs_put_write_pending() as the common writeback
completion helper; do_write_block() only ends writeback for order-0
folios.
- 08/15: move the write_pages_pending increment from move_data_page()
into f2fs_do_write_data_page(), take it only after
__folio_start_writeback(), and drop it on every error path.
move_data_page() no longer adjusts write_pages_pending or clears
gcing on error [1].
- 02/15: compute bio_offset/bio_len against the folio actually added to
the bio [5].
- 05/15, 06/15: fix the order-0 dirty accounting leak in the cp_error
path [2].
- 10/15: allocate ffs before f2fs_truncate_read_extent() [4].
- 11/15: move the existing truncated-page handling into
f2fs_clear_truncated_page_state() and reuse it for the subpage-aware
large-folio writeback path, including the -ENOENT/NULL_ADDR case [2].
Link to v5: [6]
Many thanks to Chao, Daeho and Jaegeuk for the reviews, and to the
kernel test robot for the report.
[1] https://lore.kernel.org/oe-lkp/202610081027.b13dcf10-lkp@intel.com
[2] https://lore.kernel.org/r/6be679d1-d8ab-41b3-9975-1f1bcd552579@kernel.org
[3] https://lore.kernel.org/r/fc101bc7-6ece-4a30-9e19-9b32376489a8@kernel.org
[4] https://lore.kernel.org/r/36220ef3-5b00-4aa1-ad11-60b10857a886@kernel.org
[5] https://lore.kernel.org/r/atA8dsZ35E6wTMD6@google.com
[6] https://lore.kernel.org/r/20261014064445.2835813-1-zhaonanzhe@xiaomi.com/
Nanzhe Zhao (15):
f2fs: extend folio state for large folio write path
f2fs: carry subpage offset and count in write IO
f2fs: support regular file buffered writes on large folios
f2fs: support atomic file large folios buffered write
f2fs: support large folio writeback
f2fs: account large folio dirty data at block granularity
f2fs: prepare mmap write faults for large folios
f2fs: make GC migration large-folio aware
f2fs: optimize small block size large folio read
f2fs: support partial uptodate large folio read
f2fs: handle partial truncate of large folio dirty subpages
f2fs: fix zeroing paths for large folios
f2fs: handle block cloning within the same large folio
f2fs: allow large folio support to writeable files
f2fs: make compressed files compatible with large folio
Documentation/filesystems/f2fs.rst | 10 +
fs/f2fs/checkpoint.c | 40 +-
fs/f2fs/compress.c | 7 +-
fs/f2fs/data.c | 1550 +++++++++++++++++++++++++---
fs/f2fs/dir.c | 2 +-
fs/f2fs/f2fs.h | 182 +++-
fs/f2fs/file.c | 269 +++--
fs/f2fs/gc.c | 51 +-
fs/f2fs/inline.c | 3 +-
fs/f2fs/inode.c | 4 +-
fs/f2fs/namei.c | 1 +
fs/f2fs/node.c | 2 +-
fs/f2fs/segment.c | 13 +-
13 files changed, 1869 insertions(+), 265 deletions(-)
--
2.43.0
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next reply other threads:[~2026-10-28 15:44 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-28 15:43 Nanzhe Zhao [this message]
2026-10-28 15:43 ` [f2fs-dev] [PATCH v8 01/15] f2fs: extend folio state for large folio write path Nanzhe Zhao
2026-10-29 1:30 ` Chao Yu via Linux-f2fs-devel
2026-10-28 15:43 ` [f2fs-dev] [PATCH v8 02/15] f2fs: carry subpage offset and count in write IO Nanzhe Zhao
2026-10-29 1:31 ` Chao Yu via Linux-f2fs-devel
2026-10-28 15:43 ` [f2fs-dev] [PATCH v8 03/15] f2fs: support regular file buffered writes on large folios Nanzhe Zhao
2026-10-29 1:31 ` Chao Yu via Linux-f2fs-devel
2026-10-28 15:43 ` [f2fs-dev] [PATCH v8 04/15] f2fs: support atomic file large folios buffered write Nanzhe Zhao
2026-10-29 1:31 ` Chao Yu via Linux-f2fs-devel
2026-10-28 15:43 ` [f2fs-dev] [PATCH v8 05/15] f2fs: support large folio writeback Nanzhe Zhao
2026-10-29 1:32 ` Chao Yu via Linux-f2fs-devel
2026-10-28 15:43 ` [f2fs-dev] [PATCH v8 06/15] f2fs: account large folio dirty data at block granularity Nanzhe Zhao
2026-10-29 1:32 ` Chao Yu via Linux-f2fs-devel
2026-10-28 15:43 ` [f2fs-dev] [PATCH v8 07/15] f2fs: prepare mmap write faults for large folios Nanzhe Zhao
2026-10-29 1:32 ` Chao Yu via Linux-f2fs-devel
2026-10-28 15:43 ` [f2fs-dev] [PATCH v8 08/15] f2fs: make GC migration large-folio aware Nanzhe Zhao
2026-10-29 1:32 ` Chao Yu via Linux-f2fs-devel
2026-10-28 15:44 ` [f2fs-dev] [PATCH v8 09/15] f2fs: optimize small block size large folio read Nanzhe Zhao
2026-10-29 1:33 ` Chao Yu via Linux-f2fs-devel
2026-10-28 15:44 ` [f2fs-dev] [PATCH v8 10/15] f2fs: support partial uptodate " Nanzhe Zhao
2026-10-29 1:33 ` Chao Yu via Linux-f2fs-devel
2026-10-28 15:44 ` [f2fs-dev] [PATCH v8 11/15] f2fs: handle partial truncate of large folio dirty subpages Nanzhe Zhao
2026-10-29 1:34 ` Chao Yu via Linux-f2fs-devel
2026-10-28 15:44 ` [f2fs-dev] [PATCH v8 12/15] f2fs: fix zeroing paths for large folios Nanzhe Zhao
2026-10-29 1:34 ` Chao Yu via Linux-f2fs-devel
2026-10-28 15:44 ` [f2fs-dev] [PATCH v8 13/15] f2fs: handle block cloning within the same large folio Nanzhe Zhao
2026-10-29 1:35 ` Chao Yu via Linux-f2fs-devel
2026-10-28 15:44 ` [f2fs-dev] [PATCH v8 14/15] f2fs: allow large folio support to writeable files Nanzhe Zhao
2026-10-29 1:36 ` Chao Yu via Linux-f2fs-devel
2026-10-28 15:44 ` [f2fs-dev] [PATCH v8 15/15] f2fs: make compressed files compatible with large folio Nanzhe Zhao
2026-10-29 1:36 ` Chao Yu via Linux-f2fs-devel
2026-10-29 7:12 ` Chao Yu via Linux-f2fs-devel
2026-10-29 15:17 ` Jaegeuk Kim via Linux-f2fs-devel
2026-10-28 17:34 ` [f2fs-dev] [PATCH v8 00/15] f2fs: support & optimize large folios for writable files Jaegeuk Kim via Linux-f2fs-devel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261028154407.1601430-1-nzzhao.sigma@gmail.com \
--to=nzzhao.sigma@gmail.com \
--cc=David.Hildenbrand@arm.com \
--cc=Dev.Jain@arm.com \
--cc=Ryan.Roberts@arm.com \
--cc=baohua@kernel.org \
--cc=chao@kernel.org \
--cc=daehojeong@google.com \
--cc=jaegeuk@kernel.org \
--cc=jyescas@google.com \
--cc=kaleshsingh@google.com \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lipengfei28@xiaomi.com \
--cc=nzzhao@126.com \
--cc=zhangbo56@xiaomi.com \
--cc=zhaonanzhe@xiaomi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.