From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 CDE2D493648 for ; Sat, 22 Aug 2026 07:31:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787383882; cv=none; b=WDDgcm/XtywTvdRzLppavgGH2DpY2yv8ITubT+BtwqtsgzPax0F/E5JBEWYKCmap7hZP0jQf8mnFotHk79v+/uOndcTBiJjAhiaVsq2Uejme9Nip/G/flciSZ45omEQrCX22zAJOs019aS6ZxYoYHxx9c5RQrjBw/4caEhQyAY4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787383882; c=relaxed/simple; bh=o3wJMaxfGi2sr0UgA77TBEVCj5c4fj8vsvyobIumIzg=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=cCAChXc82KtSF1kd5pZVIIQgOzBhbZ+xj3+NQVzIbipoxAfnXyMhqM/It/Ppnlt1fX0irGM/zej7Pg/rjjs0CY6fw2Mf674LxGPfVOgw3XzUgJZrvd0Lh4+FFEaSazqhXlBTSyU8cC3ScJvCuH/A9AUB3zEQnR5l4aVahismr4g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YfvuZHCz; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YfvuZHCz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 96CAB1F00A3A; Sat, 22 Aug 2026 07:31:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787383880; bh=Dh4yj5g3DJLQv20sk/xYAThxnfnOnsHLIQvEYHkzTKw=; h=Date:Cc:Subject:To:References:From:In-Reply-To; b=YfvuZHCzOkpLyRMPEE5QNylEygOUv353gzCkc5zkmOu5stwuirfm8ZYoSFAh/uw2p AHFxkZarw700G7cL/QjfDywYLxv9dijiMV9HDKnFBj8pwSlto8aGEv/oDRLR/jLspX jjWwsTcA0Dxq0XJazT9FuvdXrwrg/R3OH5RqxEm8Yxfh3WUnH7Zqp3wfXtRCUNk3wr 16FoLToUnx9NjKexiiYM4EFNDvvLrqtsy3ewN6QUQWz8P4YSURR4yxxhjrYvsspq5a EEAF79p5bLfZ1EtDu2/EPOO97nrzykLqLW51+UplNK6jnAc6BLB76i/tttaEw2AKnr 50xAq9JTRk+IA== Message-ID: <55ce8604-aa44-4e77-ba07-80689567fcf2@kernel.org> Date: Sat, 22 Aug 2026 15:31:15 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: chao@kernel.org, Daeho Jeong , kernel-team@android.com, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, =?UTF-8?B?7KCV7ISg66+8?= Subject: Re: [f2fs-dev] [PATCH] f2fs: accurately adjust free_sections during free_segment_range To: Daeho Jeong , Yeongjin Gil References: <20260818171412.3201082-1-daeho43@gmail.com> <0e1162de-1ad4-4c24-a5c9-cd05c5b08cc0@kernel.org> <8c21e8cb-00ba-497b-94a8-55219e14653f@kernel.org> <001401dd3147$17b1f300$4715d900$@samsung.com> Content-Language: en-US From: Chao Yu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/22/26 00:49, Daeho Jeong wrote: > On Fri, Aug 21, 2026 at 1:29 AM Yeongjin Gil wrote: >> >>> On Thu, Aug 20, 2026 at 6:19 AM Chao Yu wrote: >>>> >>>> On 8/20/26 02:26, Daeho Jeong wrote: >>>>> On Tue, Aug 18, 2026 at 8:57 PM Chao Yu wrote: >>>>>> >>>>>> On 8/19/26 01:14, Daeho Jeong wrote: >>>>>>> From: Daeho Jeong >>>>>>> >>>>>>> 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? 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 >>>>>>> Signed-off-by: Sunmin Jeong >>>>>>> --- >>>>>>> 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@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel >> >>