From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9B90B3CE09B for ; Fri, 5 Jun 2026 09:11:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=203.254.224.24 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780650706; cv=none; b=GrZUzpOms4YDzb6HOTY0jCCEsnfyagYeHiNQL0K9t7gh+eHZTfa+ru57xICVsUesLy+GKRy6hw2VjTo8pCW0AipO3W7I0o35fxJGHg5z+XxTehDGznks7I2V9aRkQlA0uVm3oKJf4ptu6OGV5xhRdOFHtZKQDVfRC88xHDaSW1A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780650706; c=relaxed/simple; bh=4MmgGpbegHIwvknXVlrS97+mDVRW9yhLXvHlpQeDO6c=; h=Mime-Version:Subject:From:To:CC:Message-ID:Date:Content-Type: References; b=TnCNbe/6vybSleeIHr7RjB2h2iXAMgW8SSfzmRXcZ/HSpMxCspFLJ/7L+qDYQpq9E8Li1fX72YD7mmDJBiVH39vrroI/Hj42H19PyGzDPRXTwkDAGsJeqB4Tt7SbQn8VvS98q0OdKeV+pAolUWmHeMXu6Gd1ToqIjAdUWmz0P7o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=samsung.com; spf=pass smtp.mailfrom=samsung.com; dkim=pass (1024-bit key) header.d=samsung.com header.i=@samsung.com header.b=Sm915RmF; arc=none smtp.client-ip=203.254.224.24 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=samsung.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=samsung.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=samsung.com header.i=@samsung.com header.b="Sm915RmF" Received: from epcas2p2.samsung.com (unknown [182.195.41.54]) by mailout1.samsung.com (KnoxPortal) with ESMTP id 20260605091140epoutp019270f9e828526c1fd7137232b98fc138~2JGDJS7Gn1388313883epoutp011 for ; Fri, 5 Jun 2026 09:11:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.samsung.com 20260605091140epoutp019270f9e828526c1fd7137232b98fc138~2JGDJS7Gn1388313883epoutp011 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1780650700; bh=fRvQ0uFz1O3IyQbw8MT5KRHmu8290vtJA5Shz/WUb3w=; h=Subject:Reply-To:From:To:CC:Date:References:From; b=Sm915RmF0qhWZ3XG0LrRZFlh2JFOLMSsGMmHbNevEjJ8YIwCiqRheXeOdccqjQTLw 1hPSybmoMWvuiDPkHvhATk4kbRXLVebjG5eCOlqDq5EIvKw6AOd8ZWdyZl39u0dM3w 9fJ0JmQpKdEBDG/Dt1avLVh2jZiMje+w1Hxv3d1E= Received: from epsnrtp01.localdomain (unknown [182.195.42.153]) by epcas2p2.samsung.com (KnoxPortal) with ESMTPS id 20260605091140epcas2p2023718cad3e4f7e5ed8fded7bece5421~2JGC4Dln_0290902909epcas2p2z; Fri, 5 Jun 2026 09:11:40 +0000 (GMT) Received: from epcas2p2.samsung.com (unknown [182.195.38.206]) by epsnrtp01.localdomain (Postfix) with ESMTP id 4gWwfh17Jwz6B9m6; Fri, 5 Jun 2026 09:11:40 +0000 (GMT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Subject: [PATCH v2 0/2] f2fs: pack same-inode blocks by inode during FG_GC Reply-To: daejun7.park@samsung.com Sender: Daejun Park From: Daejun Park To: "jaegeuk@kernel.org" , "chao@kernel.org" , "linux-kernel@vger.kernel.org" , "linux-f2fs-devel@lists.sourceforge.net" CC: Daejun Park X-Priority: 3 X-Content-Kind-Code: NORMAL X-CPGS-Detection: blocking_info_exchange X-Drm-Type: N,general X-Msg-Generator: Mail X-Msg-Type: PERSONAL X-Reply-Demand: N Message-ID: <20260605091139epcms2p2b17a6e7962b7c9b8fb058e1c55cd4dba@epcms2p2> Date: Fri, 05 Jun 2026 18:11:39 +0900 X-CMS-MailID: 20260605091139epcms2p2b17a6e7962b7c9b8fb058e1c55cd4dba Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Sendblock-Type: AUTO_CONFIDENTIAL CMS-TYPE: 102P X-CPGSPASS: Y X-CPGSPASS: Y cpgsPolicy: CPGSC10-223,Y X-CFilter-Loop: Reflected X-CMS-RootMailID: 20260605091139epcms2p2b17a6e7962b7c9b8fb058e1c55cd4dba References: 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