mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Daejun Park <daejun7.park@samsung.com>
To: "jaegeuk@kernel.org" <jaegeuk@kernel.org>,
	"chao@kernel.org" <chao@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-f2fs-devel@lists.sourceforge.net"
	<linux-f2fs-devel@lists.sourceforge.net>
Cc: Daejun Park <daejun7.park@samsung.com>
Subject: [PATCH v2 0/2] f2fs: pack same-inode blocks by inode during FG_GC
Date: Fri, 05 Jun 2026 18:11:39 +0900	[thread overview]
Message-ID: <20260605091139epcms2p2b17a6e7962b7c9b8fb058e1c55cd4dba@epcms2p2> (raw)
In-Reply-To: <CGME20260605091139epcms2p2b17a6e7962b7c9b8fb058e1c55cd4dba@epcms2p2>

Hi,

FG_GC migrates a victim section's valid blocks in source segment-offset
order, so blocks from several inodes stay interleaved in the destination
curseg and post-GC files stay fragmented.  This series migrates them in
inode order instead, producing inode-contiguous runs across the section.

Patch 1 is a pure refactor (extract do_migrate_one_data_block()).
Patch 2 records each valid block on a per-inode list in phase 3 and
drains it in inode order via pack_gc_section() once the section has been
scanned.  It is gated on a sysfs knob (gc_inode_local_packing, default
on for large sections) and FG_GC only; on slab alloc failure a block
falls back to immediate migration.

Changes since v1:
  - patch 2: fix seg_freed accounting.  Migration is deferred to
    pack_gc_section(), so the in-loop 'freed:' check saw the source still
    valid and seg_freed stayed 0; f2fs_gc() then under-counted sec_freed
    and a sync F2FS_IOC_GC returned -EAGAIN despite freeing space.
    seg_freed is now recomputed after the pack pass.
  - patch 2: clear next_victim_seg on the freezing 'goto stop' path,
    where queued blocks are dropped un-migrated.
  - patch 2: bound the packing queue (MAX_GC_PACK_BLOCKS) and drain it in
    batches instead of holding a whole section's records.
  - patch 1: unchanged.
  - rebased onto current f2fs/dev.

Results (QEMU guest):
  - large section (-s 32, 64 x 4 MiB): post-GC extents 65536 -> 49170
    (-24 %).
  - natural FG_GC, 90 % full, 300 s hot/cold rewrite: cold-file extents
    -63 %, move_blks -18 %, skipped_gc_rwsem -59 %.
  - seg_freed regression test (new): packing now matches the legacy path
    (seg_freed 152, sec_freed 38, 24/24 sync ioctls succeed); on v1 the
    packing column was 0/0/0 with every ioctl returning -EAGAIN.

Data sha256 is preserved across GC; a FAULT_SLAB_ALLOC run exercises the
alloc-failure fallback with a clean dmesg.

Daejun Park (2):
  f2fs: extract do_migrate_one_data_block() helper for GC migration
  f2fs: pack same-inode blocks by inode during FG_GC

 Documentation/ABI/testing/sysfs-fs-f2fs |  10 +
 fs/f2fs/f2fs.h                          |   7 +-
 fs/f2fs/gc.c                            | 271 +++++++++++++++++++-----
 fs/f2fs/gc.h                            |   1 +
 fs/f2fs/super.c                         |   1 +
 fs/f2fs/sysfs.c                         |   7 +
 6 files changed, 240 insertions(+), 57 deletions(-)


base-commit: c0b65f6129c7fbb526e921dd60261650f1b2bef9
-- 
2.43.0


       reply	other threads:[~2026-06-05  9:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20260605091139epcms2p2b17a6e7962b7c9b8fb058e1c55cd4dba@epcms2p2>
2026-06-05  9:11 ` Daejun Park [this message]
     [not found]   ` <CGME20260605091139epcms2p2b17a6e7962b7c9b8fb058e1c55cd4dba@epcms2p4>
2026-06-05  9:12     ` [PATCH v2 1/2] f2fs: extract do_migrate_one_data_block() helper for GC migration Daejun Park
     [not found]   ` <CGME20260605091139epcms2p2b17a6e7962b7c9b8fb058e1c55cd4dba@epcms2p7>
2026-06-05  9:13     ` [PATCH v2 2/2] f2fs: pack same-inode blocks by inode during FG_GC Daejun Park
2026-06-29 12:08       ` Chao Yu
     [not found]       ` <CGME20260605091139epcms2p2b17a6e7962b7c9b8fb058e1c55cd4dba@epcms2p3>
2026-06-30 10:23         ` Daejun Park
2026-06-30  4:25     ` Daejun Park

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=20260605091139epcms2p2b17a6e7962b7c9b8fb058e1c55cd4dba@epcms2p2 \
    --to=daejun7.park@samsung.com \
    --cc=chao@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®