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 0862C17993 for ; Thu, 25 Jun 2026 07:09:28 +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=1782371370; cv=none; b=ZwXGNrDZOXL0aM7prK+h1YtgvMrKR9nm3aFxG9QdnOArjouEFKx39/5B0JVA9TUinjBxv0di6l/Fi/BIjgRYAGc6pHdGVxjSmqAc+49MEIHmCpmP/dkv+pLS8idnygRR6au9uqZaXWtrCx8A38hSwTnc1XrHi2xW23lWJp3pptI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782371370; c=relaxed/simple; bh=Ws0IdjzE2XnyaLeaMV12fc+fWQuy1/bmAwuvHhYYFH4=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=ibccBoJn7hY+o7O2i7/I5q/+9wq6ZU01YaSj/6OIxtCVs847Al+MVQezzJSVA200rVRqaHsApcAZONBj1dxCUXQXoltj5sIGcyUsQ3XG56W0wHaqeptfQ9OESU7zJ6KsVuglSUW6y1nA8+TpP0gmDfPdbmvuh7PI3ItKcvtLkn4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cjH6ojaf; 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="cjH6ojaf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5326E1F000E9; Thu, 25 Jun 2026 07:09:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782371368; bh=EhW6mFsXgVvemOLRz8lv4SbjFuzlu7LDeYPY3JKfal8=; h=Date:Cc:Subject:To:References:From:In-Reply-To; b=cjH6ojafBp2aj8NQEVOEHdzaslGK9lzr6bbFLd04S8zSFlEqIxRp7La+fOHABIEFX iCNoPVxovWg3Qx9TRqivSxeY0c0x5jtE/g7RXC0o3rGiF9KBm61Bn6n34KeAzL7jas vDj+Z++Y2HASBoSPjt8G+uONdJjUk9y8Bq/Fatf4JwpoXmDlQTKT7zvjBS61y3mBHy FyVDaRHQIOsRm4dvtr0QHzFdp8Yq5BuNVH/ctT3XkeJxGblJrK8CGCma/aBKbs5TX6 nwjZHOtwJJ0VqZqMX4p8iQ2o0MbZH2+oE2uLeP8hPVPHHag/YYfCSg2zEObO7XYI2I rrRxhbyx8m9mA== Message-ID: <2d9c5628-7f99-47f8-9d51-ac64352af4d9@kernel.org> Date: Thu, 25 Jun 2026 15:09:25 +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, 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 To: Jiucheng Xu , Jaegeuk Kim References: <20260620-origin-dev-v1-1-3b2e639e794c@amlogic.com> Content-Language: en-US From: Chao Yu In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 6/22/26 18:40, Jiucheng Xu wrote: > > On 6/22/2026 9:46 AM, Chao Yu wrote: >> [Some people who received this message don't often get email from chao@kernel.org. Learn why this is important at https://aka.ms/ LearnAboutSenderIdentification ] >> >> [ EXTERNAL EMAIL ] >> >> On 6/20/26 17:34, Jiucheng Xu via B4 Relay wrote: >>> From: Jiucheng Xu >>> >>> 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... > > Hi Chao, > > Thanks for your feedback. I just do a test to simulate the Android OTA createCowImage failed when dirty_segments is too large. > > Simple reproduction steps: > 1. In my case, dirty_segments=969, free_segments=96, free space = 1.7G, section:segment = 1:1 > 2. touch a.bin > 3. f2fs_io pinfile set a.bin > 4. fallocate -l 1.5G a.bin > > And f2fs_fallocate() returns -11. > > Although the urgent mode work fine, but it is not very convenient to control since AOPS has a great deal of code that calls fallocate. > > I have tried 5 times to fallocate(), but GC always selects the same victim segno. So I think it is an issue. > > > The trace: > f2fs_get_victim: dev = (254,0), type = No TYPE, policy = (Foreground GC, LFS-mode, Greedy), victim = 624, cost = 19... > > f2fs_gc_end: dev = (254,0), ret = 0, seg_freed = 0, sec_freed = 0, nodes = 117, dents = 0, imeta = 98, free_sec:50, free_seg:50, rsv_seg:47, prefree_seg:47 > > > I dump the failed victim segno, block offset in segment and related inode ino: > do_garbage_collect: ino=33902 segno=624 off=132 > > The dump of pinfile 33902 info: > main_blkaddr                            [0x    2600 : 9728] > i_inline                                [0x      61 : 97] > inline shows the file is pinned (0x60) > i_addr[0x9]                             [0x   2f7b2 : 194482] > i_addr[0xa]                             [0x   2f7b3 : 194483] > i_addr[0xb]                             [0x   2f7b4 : 194484] > ... > i_addr[0x1d]                            [0x   2f7c6 : 194502] > i_addr[0x1e]                            [0x   465af : 288175] > i_addr[0x1f]                            [0x   465b0 : 288176] > ... > i_addr[0x21]                            [0x   465b2 : 288178] > i_addr[0x22]                            [0x   5046d : 328813] > i_addr[0x23]                            [0x   5046e : 328814] > i_addr[0x24]                            [0x   505b6 : 329142] > i_addr[0x25]                            [0x   505b7 : 329143] > i_addr[0x26]                            [0x   505b8 : 329144] > i_addr[0x27]                            [0x   50684 : 329348] > i_addr[0x28]                            [0x   50685 : 329349] > > The file is created by logcat,and looks like indeed fragmented. > > Calculate the block address: > 624 * 512 + 132 + 9728(main_blkaddr) = 329348 > > So the i_addr[0x27] = 329348 is the failed block. > > Regarding "why the pinfile is fragmented" you said, we use v5.15 + android U. Is it that v5.15 lacks some patches for special handling of pinfiles? Ah, I think you can unpin log file created by logcat, the flag is added in aosp/1014260 to avoid fragmentation in filesystem (), but it's gone in aosp/43c6d76a Thanks, > > Thanks, > > >> >> Thanks, >> >>> >>> Signed-off-by: Jiucheng Xu >>> --- >>>   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, >> >