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 6C79C261B8A for ; Thu, 20 Aug 2026 23:52:10 +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=1787269931; cv=none; b=h99JY5yuAhEa7P0jpflGWruqZDHeyig/xTdzZgBIu6Y7SNLLAjkfTUgb5AzqXbnRJeUn4+cu0w644wy5oMmvm7P2KqbF4JVc9P4lErt72I8KogLlph1BQS3qA1nQDGcuaRU2nbqz2HzjqjfRJk+J1k/+x8nNvc5TuVaRyl3uwS4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787269931; c=relaxed/simple; bh=B3Z1NQe9OmTGflAqUTgC0MyhHGHZridp6TCvIf1+koY=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=Lo5WY/4eQ1jL+kPXlpyapimahcNa9Du7uhVXQ1X21I5MdZjhtkBSjl8Z9EhLube5/uSZtvjGqNP5r4DzpE1ZFeSdbrloF8KGxogQb7JHKTf+JvfzzmM0+b1ueg8FkWrXDgWAz9gcIrN8TioDTiLcl84M/+kCUhSoT4GITQl4Neg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AGdoBk4Z; 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="AGdoBk4Z" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 208BB1F000E9; Thu, 20 Aug 2026 23:52:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787269930; bh=NbZgEP2jtLb0zDRuTTx1wqr8n4blUjQ30H0Se2VZ7V4=; h=Date:Cc:Subject:To:References:From:In-Reply-To; b=AGdoBk4ZwdPFVCtF/6TcPSezuzLn+j0b9px0owJeFroU51m2gDBPPqLZijBLnFMxs s01KfNYgBe2a3mZfGtHQtLpGH7bbYsL4TnpQhwfHm7CHWT15yFEXpU2o4vE119ULG8 itd1zbRdq9NPqnjmtKVABdzitjb8FPiembn3FYalXJxoydEGEAfGBzORlQVSm9C+Ev iTITsXzTYsRtcmHooZ3eepB47+9LiMplnKLUk74TiZi5x7niFexDKB/pkrHPYPn4Vz O/lwcLZ/L7j1AhK48Lb5oWk0SIhsCaM7slBCAghvyeNDZPudoWYkXa0qCYZT+bMb41 LVdrSp4cePmnA== Message-ID: <55fed9d7-cec1-42f8-9b79-19a95bacb340@kernel.org> Date: Fri, 21 Aug 2026 07:52:06 +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 Subject: Re: [f2fs-dev] [PATCH v2] f2fs: avoid setting SBI_NEED_FSCK on transient resize failure To: Daeho Jeong , linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, kernel-team@android.com References: <20260820164340.2802152-1-daeho43@gmail.com> Content-Language: en-US From: Chao Yu In-Reply-To: <20260820164340.2802152-1-daeho43@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/21/26 00:43, Daeho Jeong wrote: > From: Daeho Jeong > > When free_segment_range() fails in f2fs_resize_fs(), no on-disk > superblock or filesystem metadata has been modified yet, and > free_segment_range() safely restores all in-memory counters before > returning. > > However, the current error recovery path unconditionally sets the > SBI_NEED_FSCK flag and prints a scary error message on any error, > forcing an unnecessary and time-consuming fsck.f2fs repair on the > subsequent mount/reboot. > > Fix this by separating the error recovery path with a dedicated > recover_user_blocks label to bypass setting SBI_NEED_FSCK on > free_segment_range() failures. > > Signed-off-by: Daeho Jeong > Signed-off-by: Sunmin Jeong Reviewed-by: Chao Yu Thanks,