Re: [PATCH] f2fs: fix FG GC failure when file in victim is pinned

From: Chao Yu

Date: Sun Jun 21 2026 - 21:46:54 EST


On 6/20/26 17:34, Jiucheng Xu via B4 Relay wrote:
From: Jiucheng Xu <jiucheng.xu@xxxxxxxxxxx>

When continuous write operations occur in the system, BG GC fails to
work. This leads to large dirty_segments and small free_segments. If
fallocate() is performed on a pinned file with the allocated space
exceeding the free_segment, FG_GC reclamation fails.

The reason is that the file corresponding to the block in the victim is
pinned, causing gc_data_segment() to fail. Since the condition sec_freed

Jiucheng,

pinned file should be aligned to section size, why there is fragmented blocks
of pinfile locates in dirty sections?

< gc_control->nr_free_secs isn't satisfied, GC stops, resulting in the
failure of f2fs_fallocate() allocation.

Setting gc_control->nr_free_secs = 1 make FG GC continue searching
for new victim.

Maybe we can try this instead of changing f2fs_expand_inode_data() logic:
1. call fggc via ioctl or trigger urgent gc via sysfs
2. fallocate on pinfile, goto 1) if it failed

But, anyway, I suspect it's risk, if there is no normal dirty section,
FGGC will try to call f2fs_unpin_all_sections(), then migrate dirty section
which has pinned blocks, that will cause more damage.

Can you please figure out why pinfile is fragmented first...

Thanks,


Signed-off-by: Jiucheng Xu <jiucheng.xu@xxxxxxxxxxx>
---
fs/f2fs/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 8acdd94272a0ced448e0ba21635d702cfec10682..3e49a73bbf3a184a314e97bff9509a66c27eac00 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -1883,7 +1883,7 @@ static int f2fs_expand_inode_data(struct inode *inode, loff_t offset,
.init_gc_type = FG_GC,
.should_migrate_blocks = false,
.err_gc_skipped = true,
- .nr_free_secs = 0 };
+ .nr_free_secs = 1 };
pgoff_t pg_start, pg_end;
loff_t new_size;
loff_t off_end;

---
base-commit: b51f606aa323d553d786ed681a213f134dc688d6
change-id: 20260620-origin-dev-99cdccc83800

Best regards,