All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.