From: Jaegeuk Kim via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: Chao Yu <chao@kernel.org>
Cc: Yongpeng Yang <yangyongpeng@xiaomi.com>,
Yongpeng Yang <monty_pavel@sina.com>,
Yongpeng Yang <yangyongpeng.storage@gmail.com>,
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [RFC PATCH v2 0/5] f2fs: introduce inline extent mapping for inode data blocks
Date: Thu, 2 Jul 2026 14:30:03 +0000 [thread overview]
Message-ID: <akZ161iaNMoem0wy@google.com> (raw)
In-Reply-To: <7862f9d0-278f-4bf8-ae6b-9413dc52f841@kernel.org>
On 06/25, Chao Yu via Linux-f2fs-devel wrote:
> Sorry for the delay.
>
> On 5/29/26 16:56, Yongpeng Yang wrote:
> > From: Yongpeng Yang <yangyongpeng@xiaomi.com>
> >
> > Changes since v1:
> > - Introduce tracepoints for f2fs_iext_update_data_blkaddr and
> > f2fs_iext_lookup_blkaddr to aid debugging (new patch 5/5).
> > - Bypass inline extent lookup for F2FS_GET_BLOCK_PRECACHE to ensure all
> > mappings are loaded into the read extent cache.
> > - Unify the check for fofs exceeding direct_blocks range to use
> > "fofs >= direct_blocks" consistently.
> > - Remove support for caching NULL_ADDR in inline extent area. If a fofs
> > within [0, direct_blocks) is not found in inline extent, it implies
> > NULL_ADDR. This simplifies merge and split logic.
> > - Fix f2fs_iext_enable_inline_extent to use PTR_ERR instead of -ENOMEM.
> > - Change f2fs_iext_convert_to_inline_extent return type to bool.
> > - Add benchmark data covering 4K/8K/32K/64K random read.
> > - Rename __is_extent_mergeable to __is_iextent_mergeable to avoid
> > naming collision with extent cache code.
> > - Remove inode parameter from f2fs_iext_sanity_check (always NULL).
> > - Reduce #ifdef CONFIG_F2FS_INLINE_EXTENT nesting in node.c.
> > - Code style fixes to comply with kernel coding style.
> >
> > This patchset introduces an inline extent mapping mechanism for f2fs.
> > Instead of storing individual block addresses in the inode's data block
> > address area (i_addr[]), this feature packs contiguous block ranges into
> > compact extent entries, significantly reducing the number of entries
> > needed and enabling faster block address lookups via binary search.
> >
> > The inline extent format is identified by magic numbers in the inode
> > data area and is transparent to the rest of f2fs -- when the extent
> > area is full or cannot represent the mapping efficiently, it
> > automatically converts back to the direct block address format.
> >
> > Patch 1: Preparatory refactoring -- replace raw pointer arithmetic
> > with f2fs_data_blkaddr() to abstract block address access.
> > Patch 2: Core implementation -- data structures, extent operations
> > (lookup, insert, merge, split, truncate), format conversion,
> > and integration with f2fs data/node paths.
> > Patch 3: ioctl interface -- allow per-file enable/disable of inline
> > extent format via F2FS_EXTENT_FL flag.
> > Patch 4: sysfs interface -- runtime enable/disable toggle and file
> > extension list for automatic inline extent activation.
> > Patch 5: Tracepoints for inline extent lookup and update operations.
> >
> > Test setup and results:
> > =======================
> >
> > Platform: Xiaomi smartphone, UFS 4.0 storage
> >
> > # Enable inline extent
> > echo 1 > /sys/fs/f2fs/<dev>/inline_extent_enable
> > echo 'mp4' > /sys/fs/f2fs/<dev>/inline_extent_extension_list
> >
> > # Prepare data: write with 4K offset stride to create fragmented
> > # extents, then overwrite sequentially so inline extent can cache
> > # all mappings in compact form.
> > fio --name=test --filename=data.mp4 --rw=write:4k --bs=64M \
> > --size=8G --ioengine=libaio --direct=1
> > sync
> > fio --name=test --filename=data.mp4 --rw=write --bs=64M \
> > --size=8G --ioengine=libaio --direct=1
> > sync
> > echo 3 > /proc/sys/vm/drop_caches
> >
> > # Benchmark: random buffered read, 1GB total IO
> > fio --name=buffer-read --ioengine=libaio --rw=randread --bs=$BS \
> > --size=8G --io_size=1G --numjobs=1 --filename=data.mp4
> >
> > Results (random read bandwidth, MiB/s):
> > +---------------------------------------------------+
> > | BS | baseline | inline ext | improvement |
> > |--------+----------+------------+------------------|
> > | 4K | 35 | 36 | +2.5% |
> > | 8K | 60 | 62 | +3% |
> > | 32K | 179 | 191 | +6.8% |
> > | 64K | 284 | 321 | +13% |
> > +---------------------------------------------------+
> >
> > The improvement comes from eliminating direct/indirect node page reads
> > during block address lookup -- all mappings are stored directly in
> > the inode page and found via O(log n) binary search.
> >
> > Yongpeng Yang (5):
> > f2fs: replace raw dnode pointer arithmetic with f2fs_data_blkaddr()
> > f2fs: introduce inline extent mapping for inode data blocks
> > f2fs: support setting inline extent flag via ioctl
> > f2fs: add sysfs interface for inline extent management
> > f2fs: introduce tracepoints for inline extent lookup and update
> >
> > fs/f2fs/Kconfig | 18 +
> > fs/f2fs/Makefile | 1 +
> > fs/f2fs/data.c | 157 ++++++-
> > fs/f2fs/debug.c | 4 +
> > fs/f2fs/dir.c | 9 +
> > fs/f2fs/f2fs.h | 23 +-
> > fs/f2fs/file.c | 93 +++-
> > fs/f2fs/iextent.c | 873 ++++++++++++++++++++++++++++++++++++
> > fs/f2fs/iextent.h | 187 ++++++++
> > fs/f2fs/inline.c | 7 +
> > fs/f2fs/namei.c | 48 ++
> > fs/f2fs/node.c | 66 ++-
> > fs/f2fs/node.h | 4 +
> > fs/f2fs/recovery.c | 17 +
> > fs/f2fs/super.c | 13 +
> > fs/f2fs/sysfs.c | 52 +++
> > include/trace/events/f2fs.h | 79 ++++
> > 17 files changed, 1635 insertions(+), 16 deletions(-)
>
> It's quite a large number of change (including f2fs-tools change) to support
> this new feature, it causes the performance price ratio a little bit low.
>
> About inode disk layout, as we discuss offline, maybe we can add 4 or 8 ...
> extents in i_extra_attr area of f2fs_inode structure, it can reduce the
> change line and code complex, however, not sure how will it affect the
> benefits.
>
> To Jaegeuk, please share your thoughts on this feature.
Agreed. Can we try to add more extents simply?
>
> Thanks,
>
> > create mode 100644 fs/f2fs/iextent.c
> > create mode 100644 fs/f2fs/iextent.h
> >
>
>
>
> _______________________________________________
> 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
next prev parent reply other threads:[~2026-07-02 14:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-29 8:56 [f2fs-dev] [RFC PATCH v2 0/5] f2fs: introduce inline extent mapping for inode data blocks Yongpeng Yang
2026-05-29 8:56 ` [f2fs-dev] [RFC PATCH v2 1/5] f2fs: replace raw dnode pointer arithmetic with f2fs_data_blkaddr() Yongpeng Yang
2026-05-29 8:56 ` [f2fs-dev] [RFC PATCH v2 2/5] f2fs: introduce inline extent mapping for inode data blocks Yongpeng Yang
2026-05-29 8:56 ` [f2fs-dev] [RFC PATCH v2 3/5] f2fs: support setting inline extent flag via ioctl Yongpeng Yang
2026-05-29 8:56 ` [f2fs-dev] [RFC PATCH v2 4/5] f2fs: add sysfs interface for inline extent management Yongpeng Yang
2026-05-29 8:56 ` [f2fs-dev] [RFC PATCH v2 5/5] f2fs: introduce tracepoints for inline extent lookup and update Yongpeng Yang
2026-06-25 8:34 ` [f2fs-dev] [RFC PATCH v2 0/5] f2fs: introduce inline extent mapping for inode data blocks Chao Yu via Linux-f2fs-devel
2026-07-01 13:15 ` Yongpeng Yang
2026-07-02 14:30 ` Jaegeuk Kim via Linux-f2fs-devel [this message]
2026-07-13 13:39 ` Yongpeng Yang
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=akZ161iaNMoem0wy@google.com \
--to=linux-f2fs-devel@lists.sourceforge.net \
--cc=chao@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=monty_pavel@sina.com \
--cc=yangyongpeng.storage@gmail.com \
--cc=yangyongpeng@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox