From: Chao Yu via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: jiucheng.xu@amlogic.com, Jaegeuk Kim <jaegeuk@kernel.org>
Cc: tuan.zhang@amlogic.com, linux-kernel@vger.kernel.org,
jianxin.pan@amlogic.com, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: fix FG GC failure when file in victim is pinned
Date: Mon, 22 Jun 2026 09:46:24 +0800 [thread overview]
Message-ID: <dffacd73-ebc2-4f35-9433-d569b48014be@kernel.org> (raw)
In-Reply-To: <20260620-origin-dev-v1-1-3b2e639e794c@amlogic.com>
On 6/20/26 17:34, Jiucheng Xu via B4 Relay wrote:
> From: Jiucheng Xu <jiucheng.xu@amlogic.com>
>
> 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@amlogic.com>
> ---
> 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,
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
WARNING: multiple messages have this Message-ID (diff)
From: Chao Yu <chao@kernel.org>
To: jiucheng.xu@amlogic.com, Jaegeuk Kim <jaegeuk@kernel.org>
Cc: chao@kernel.org, linux-f2fs-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, jianxin.pan@amlogic.com,
tuan.zhang@amlogic.com
Subject: Re: [PATCH] f2fs: fix FG GC failure when file in victim is pinned
Date: Mon, 22 Jun 2026 09:46:24 +0800 [thread overview]
Message-ID: <dffacd73-ebc2-4f35-9433-d569b48014be@kernel.org> (raw)
In-Reply-To: <20260620-origin-dev-v1-1-3b2e639e794c@amlogic.com>
On 6/20/26 17:34, Jiucheng Xu via B4 Relay wrote:
> From: Jiucheng Xu <jiucheng.xu@amlogic.com>
>
> 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@amlogic.com>
> ---
> 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,
next prev parent reply other threads:[~2026-06-22 1:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-20 9:34 [PATCH] f2fs: fix FG GC failure when file in victim is pinned Jiucheng Xu
2026-06-20 9:34 ` Jiucheng Xu via B4 Relay
2026-06-20 9:34 ` [f2fs-dev] " Jiucheng Xu via B4 Relay via Linux-f2fs-devel
2026-06-22 1:46 ` Chao Yu via Linux-f2fs-devel [this message]
2026-06-22 1:46 ` Chao Yu
2026-06-22 10:40 ` Jiucheng Xu
2026-06-22 10:40 ` [f2fs-dev] " Jiucheng Xu via Linux-f2fs-devel
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=dffacd73-ebc2-4f35-9433-d569b48014be@kernel.org \
--to=linux-f2fs-devel@lists.sourceforge.net \
--cc=chao@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=jianxin.pan@amlogic.com \
--cc=jiucheng.xu@amlogic.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tuan.zhang@amlogic.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.