Re: [f2fs-dev] [PATCH] f2fs: accurately adjust free_sections during free_segment_range

[Daeho Jeong]

On Sat, Aug 22, 2026 at 12:31 AM Chao Yu <chao@xxxxxxxxxx> wrote:
>
> 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:
> >>>>
> >>>> 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
> >>> 90 .. 99).
> >>>>> - 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
> >>> by GC.
> >>>>> 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.
> >>>
> >> I wonder if the free-section adjustment could still be relevant
> >> 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?

Yes, so I think this patch is still valid for the case..

Thanks,

>
> Thanks,
>
> >
> >>
> >> Thanks,
> >>>>
> >>>> Not sure, maybe you mean other threads will call
> >>>> has_not_enough_free_secs(), are you worried about that we may miss
> >>> chances to call fggc earlier in below cases:
> >>>>
> >>>> f2fs_balance_fs -> has_enough_free_secs -> f2fs_gc? I guess it will
> >>>> blocked on gc_lock.
> >>>
> >>>>
> >>>>>        sections in the active 0 .. 89 range.
> >>>>>      - If free_segment_range() fails midway (e.g. -EAGAIN),
> >>> free_sections
> >>>>>        accounting 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 ..
> >>> 99) and
> >>>>>     deduct them from free_sections upon entering (30 - 6 = 24),
> >>> perfectly
> >>>>>     matching the actual free sections in the active range 0 .. 89.
> >>>>> - On exit, the deducted amount is restored, keeping free_sections
> >>> consistent
> >>>>>     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
> >>> under segmap_lock on exit.
> >>>>>>>
> >>>>>>> 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
> >>> 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
> >>> free_segment_range(struct f2fs_sb_info *sbi,
> >>>>>>>                 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
> >>
> >>
>