From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 D49FC15E97 for ; Sat, 20 Jun 2026 09:34:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781948048; cv=none; b=d0FgzJKy+hS8lYKKd8bl/wStDmfGpxoPUzjQfpEw+qqq+z1WRJ7ZuxCLSuMowmzd/fkWUnVbrYX1QGMuuLbB+m1srXoFK0gHlt/Uy1n6Sifr+Rdy4Z3IvOFv0u9WeANZgXp54pfmmLswuAI0o/wKvZtgtMMcx08/oSyEGH9cmVo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781948048; c=relaxed/simple; bh=8+Kj4od/en0jCRi1eRM+TjoBTe2DN5iENFai63QL33E=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=EcEsChbdO9i6LL3Ktnqk5HUFDGt9+21e9d207cTcI56UAgH0nHifK6btqCGVj7mqn8R8Mjs3L+FEZjJKuxTQdu3HTkGh1+Cu08ZfCQ7ZqsaHQ8XuvQ8GQfgrUSMojlQDNjgPALU5jP9fePZ8clvPfoCTIBXmpIvsxj/nFEbqxyc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ov+q6ee7; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ov+q6ee7" Received: by smtp.kernel.org (Postfix) with ESMTPS id 69C0FC2BCB0; Sat, 20 Jun 2026 09:34:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1781948048; bh=8+Kj4od/en0jCRi1eRM+TjoBTe2DN5iENFai63QL33E=; h=From:Date:Subject:To:Cc:Reply-To:From; b=ov+q6ee7dHN8LWCz8OFh5iBsp+epDRXHg/z3bHq3YH4gsXvFUKrtrdrjgnKcCY6ng AEJH8+U+r354+YiMiBoNG0mhm2G7EJFN7vDef71vzvPyxDv9kHh2whBRpDKqUCu/Di T9LfWjDg81rWj5zxko43P0O0zQeH3JJZu7UqLwN7xv711ze7CcMYLr9vMvoW7Sd5Yv 3y3GWwBeW1hrh0kw3Mxrpi+YgM8GWH/C5zxJj/nTFxj9VazbH94RCS4RBN5hx+Xwfy wsHe+98is9B3Dyc1ThCo5ML0aJL8xvOuPG5QccSdsmLWS8xEJpAf01GL1KEYXfclND Ar+VuUhvZeBvQ== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 582AECD98F2; Sat, 20 Jun 2026 09:34:08 +0000 (UTC) From: Jiucheng Xu via B4 Relay Date: Sat, 20 Jun 2026 17:34:05 +0800 Subject: [PATCH] f2fs: fix FG GC failure when file in victim is pinned Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260620-origin-dev-v1-1-3b2e639e794c@amlogic.com> X-B4-Tracking: v=1; b=H4sIAIxeNmoC/x3MQQqAIBBA0avIrBMmA9GuEi1inGw2GgoRiHdPW r7F/w0qF+EKq2pQ+JEqOQ3MkwK6jhRZSxgGg8aiNahzkShJB3609xSIyC0OEUZwFz7l/Wfb3vs HUFYodlwAAAA= X-Change-ID: 20260620-origin-dev-99cdccc83800 To: Jaegeuk Kim , Chao Yu Cc: linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, jianxin.pan@amlogic.com, tuan.zhang@amlogic.com, Jiucheng Xu X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1781948046; l=1408; i=jiucheng.xu@amlogic.com; s=20250821; h=from:subject:message-id; bh=jxb8I4TnUJtPHsroLRoqXeQLJJ3g0yqJyXK0cin68SY=; b=0wXhatgMPTS5dc7I5i5bJ3pyFgVnevNTYeVkGK3tp06SbPEDSe6NQW8z+aZ1tlnOGmFYTQVkv ytHajwEBNytA88mid32RHSnx7pgiAshH3jae3kBJuL2MmyJGWKufa64 X-Developer-Key: i=jiucheng.xu@amlogic.com; a=ed25519; pk=Q18IjkdWCCuncSplyu+dYqIrm+n42glvoLFJTQqpb2o= X-Endpoint-Received: by B4 Relay for jiucheng.xu@amlogic.com/20250821 with auth_id=498 X-Original-From: Jiucheng Xu Reply-To: jiucheng.xu@amlogic.com 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 < 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. 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, -- Jiucheng Xu