All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jaegeuk Kim via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: Nanzhe Zhao <nzzhao.sigma@gmail.com>
Cc: Barry Song <baohua@kernel.org>,
	Nanzhe Zhao <zhaonanzhe@xiaomi.com>,
	Juan Yescas <jyescas@google.com>,
	Daeho Jeong <daehojeong@google.com>, Dev Jain <Dev.Jain@arm.com>,
	linux-kernel@vger.kernel.org,
	David Hildenbrand <David.Hildenbrand@arm.com>,
	linux-f2fs-devel@lists.sourceforge.net,
	Bo Zhang <zhangbo56@xiaomi.com>,
	Kalesh Singh <kaleshsingh@google.com>,
	Nanzhe Zhao <nzzhao@126.com>, Pengfei Li <lipengfei28@xiaomi.com>,
	Ryan Roberts <Ryan.Roberts@arm.com>
Subject: Re: [f2fs-dev] [PATCH v8 00/15] f2fs: support & optimize large folios for writable files
Date: Wed, 28 Oct 2026 17:34:43 +0000	[thread overview]
Message-ID: <auIyM-RmQE3rx1XL@google.com> (raw)
In-Reply-To: <20261028154407.1601430-1-nzzhao.sigma@gmail.com>

Hi Nanzhe,

I applied this series on top of the latest mainline having page private patches
where I had to clean up some conflicts. Could you please check dev-test branch?

Thanks,

On 10/28, Nanzhe Zhao wrote:
> 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


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

      parent reply	other threads:[~2026-10-28 17:34 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-28 15:43 [f2fs-dev] [PATCH v8 00/15] f2fs: support & optimize large folios for writable files Nanzhe Zhao
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-28 17:34 ` Jaegeuk Kim via Linux-f2fs-devel [this message]

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=auIyM-RmQE3rx1XL@google.com \
    --to=linux-f2fs-devel@lists.sourceforge.net \
    --cc=David.Hildenbrand@arm.com \
    --cc=Dev.Jain@arm.com \
    --cc=Ryan.Roberts@arm.com \
    --cc=baohua@kernel.org \
    --cc=daehojeong@google.com \
    --cc=jaegeuk@kernel.org \
    --cc=jyescas@google.com \
    --cc=kaleshsingh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lipengfei28@xiaomi.com \
    --cc=nzzhao.sigma@gmail.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.