Re: [f2fs-dev] [PATCH] f2fs: accurately adjust free_sections during free_segment_range
From: Chao Yu
Date: Sat Aug 22 2026 - 03:31:44 EST
On 8/22/26 00:49, Daeho Jeong wrote:
On Fri, Aug 21, 2026 at 1:29 AM Yeongjin Gil <youngjin.gil@xxxxxxxxxxx> wrote:
On Thu, Aug 20, 2026 at 6:19 AM Chao Yu <chao@xxxxxxxxxx> wrote:I wonder if the free-section adjustment could still be relevant
90 .. 99).
On 8/20/26 02:26, Daeho Jeong wrote:
On Tue, Aug 18, 2026 at 8:57 PM Chao Yu <chao@xxxxxxxxxx> wrote:
On 8/19/26 01:14, Daeho Jeong wrote:
From: Daeho Jeong <daehojeong@xxxxxxxxxx>
In free_segment_range(), MAIN_SECS(sbi) is temporarily reduced by
`secs` while valid blocks in the truncated range are evacuated by GC.
However, if any sections within the truncated range were already
free, failing to deduct them from FREE_I(sbi)->free_sections leads
to an over-estimation of available space in the reduced main area,
causing inconsistent free section accounting.
Can you please show me an example for above case? I didn't get it.
Here is a concrete example explaining why this adjustment is needed:
Thanks for the detailed explanation.
Suppose:
- Total main sections: MAIN_SECS = 100 (sections 0 .. 99)
- Total free sections: free_sections = 30
- We want to shrink the filesystem by 10 sections (secs = 10, range
by GC.- Within the truncated range (sections 90 .. 99):
* 6 sections are already free (free_secmap bit is 0)
* 4 sections are in-use with valid blocks that need to be migrated
When free_segment_range() enters:
1. MAIN_SECS is temporarily reduced from 100 to 90 so that new block
allocations are constrained to sections 0 .. 89.
2. The actual number of free sections available in the reduced range
(0 .. 89) is only 24 (30 - 6 = 24).
3. Without this patch:
- free_sections remains 30 while MAIN_SECS is 90.
- During the subsequent GC migrations, free section checks (such as
has_not_enough_free_secs()) will over-estimate available space
by 6
But free_segment_range() won't call into has_not_enough_free_secs(),
if I'm not missing anything.
Oh, right. I missed it's FG_GC.
I think we can drop this patch.
Thanks.
to the SSR/LFS allocation decision during resize.
Could you please also check whether free_sections may affect
allocation through the following paths?
free_segment_range()
-> f2fs_allocate_segment_for_resize()
-> f2fs_need_SSR()
-> new_curseg()
-> get_new_segment()
Also, when a current segment becomes full during block migration:
free_segment_range()
-> f2fs_gc_range()
-> do_garbage_collect()
-> f2fs_allocate_data_block()
-> need_new_seg()
-> f2fs_need_SSR()
-> new_curseg()
-> get_new_segment()
If free_sections still include free sections in the range being
removed, f2fs_need_SSR() may choose LFS allocation instead of SSR.
Since get_new_segment() searches only within the temporarily reduced
MAIN_SECS range, it may fail to find a free section.
Could you please confirm whether this case also needs to be handled?
Thank you for pointing this out — this is a very sharp and valid observation!
It makes sense to me. Chao, WDYT?
Daeho, yeah, I think it's a good catch from Yeongjin.
I suspect this is a bug, right?
For example, f2fs has high BDF value:
0..85 are dirty sections, and has few valid blocks in each section
86..89 are free sections
90..99 are full sections
When we migrate 90..99 to 0..89, if SSR can not used for such case,
get_new_segment() may return -ENOSPC, and trigger the panic?
Thanks,
Thanks,
chances to call fggc earlier in below cases:
Not sure, maybe you mean other threads will call
has_not_enough_free_secs(), are you worried about that we may miss
f2fs_balance_fs -> has_enough_free_secs -> f2fs_gc? I guess it will
blocked on gc_lock.
free_sections
sections in the active 0 .. 89 range.
- If free_segment_range() fails midway (e.g. -EAGAIN),
99) andaccounting becomes inconsistent.
Why free_sections accounting becomes inconsistent if
free_segment_range() fails midway?
Thanks,
With this patch:
- We count the 6 already-free sections in the truncated range (90 ..
perfectlydeduct them from free_sections upon entering (30 - 6 = 24),
consistentmatching the actual free sections in the active range 0 .. 89.
- On exit, the deducted amount is restored, keeping free_sections
under segmap_lock on exit.throughout the entire resize lifecycle.
Hope this clarifies the scenario!
Thanks,
BTW, it needs to rebase this patch on dev-test branch.
Thanks,
Fix this by calculating the number of already-free sections in the
truncated range under segmap_lock, deducting them from
free_sections upon entering free_segment_range(), and restoring them
f2fs_sb_info *sbi,
Signed-off-by: Daeho Jeong <daehojeong@xxxxxxxxxx>
Signed-off-by: Sunmin Jeong <s_min.jeong@xxxxxxxxxxx>
---
fs/f2fs/gc.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c index
787133ee2eb2..f3a6fc6d08ae 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -2200,8 +2200,9 @@ int f2fs_gc_range(struct f2fs_sb_info *sbi,
static int free_segment_range(struct f2fs_sb_info *sbi,
unsigned int secs, bool dry_run)
{
- unsigned int next_inuse, start, end;
+ unsigned int secno, next_inuse, start, end, end_secno;
struct cp_control cpc = { CP_RESIZE, 0, 0, 0 };
+ unsigned int freed_secs = 0;
int gc_mode, gc_type;
int err = 0;
int type;
@@ -2210,6 +2211,7 @@ static int free_segment_range(struct
f2fs_sb_info *sbi,MAIN_SECS(sbi) -= secs;
start = MAIN_SECS(sbi) * SEGS_PER_SEC(sbi);
end = MAIN_SEGS(sbi) - 1;
+ end_secno = GET_SEC_FROM_SEG(sbi, end);
mutex_lock(&DIRTY_I(sbi)->seglist_lock);
for (gc_mode = 0; gc_mode < MAX_GC_POLICY; gc_mode++) @@
-2221,6 +2223,14 @@ static int free_segment_range(struct
free_segment_range(struct f2fs_sb_info *sbi,sbi->next_victim_seg[gc_type] = NULL_SEGNO;
mutex_unlock(&DIRTY_I(sbi)->seglist_lock);
+ spin_lock(&FREE_I(sbi)->segmap_lock);
+ for (secno = MAIN_SECS(sbi); secno <= end_secno; secno++) {
+ if (!test_bit(secno, FREE_I(sbi)->free_secmap))
+ freed_secs++;
+ }
+ FREE_I(sbi)->free_sections -= freed_secs;
+ spin_unlock(&FREE_I(sbi)->segmap_lock);
+
/* Move out cursegs from the target range */
for (type = CURSEG_HOT_DATA; type < NR_CURSEG_TYPE; type++) {
err = f2fs_allocate_segment_for_resize(sbi, type,
start, end); @@ -2245,6 +2255,9 @@ static int
f2fs_bug_on(sbi, 1);
}
out:
+ spin_lock(&FREE_I(sbi)->segmap_lock);
+ FREE_I(sbi)->free_sections += freed_secs;
+ spin_unlock(&FREE_I(sbi)->segmap_lock);
MAIN_SECS(sbi) += secs;
return err;
}
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel