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 E727918A6DB for ; Wed, 22 Jan 2025 06:27:46 +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=1737527268; cv=none; b=HAD5wfE/dhfCzTrS4SDB8du6axebcaxfco9C57Ne/yZzHiASijDPxNmA7gJwrMBXuWfoUnvjNArTF+lOA2hNvV030uX6sCASVM5LHbKVTFtjxMl9IGlVJDf+ttdXlmRpe2HVRbTygrCUnI2JO3MOY6lYkpz9fU5BGqmM9dq0zOU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737527268; c=relaxed/simple; bh=0fNhnn0oujNo5YBIse/osBB8eQvOIr1B9Ka/JUVhE+8=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=ukY7sIfGuql3a/T7Wu6BIBGNAGeJ3Of/kgagXvIEsIOoSrdLUpwf7mxoz+juRw6EBfGSi0MHfCNruOuXcgYUtt+EK+X1CtFRY66WUMQE9gzp5aWUXxJPf9omlUA98HTYRoVyb6WOjNPCxRYrdIf6KnDCMoghJvzmDERiD5NQiAM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nStQ0q2M; 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="nStQ0q2M" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A8333C4CED6; Wed, 22 Jan 2025 06:27:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1737527266; bh=0fNhnn0oujNo5YBIse/osBB8eQvOIr1B9Ka/JUVhE+8=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=nStQ0q2MVFZz4E1Vqjezwuf+p/d6CkpsI54Gr4U8tX5DVCm9WefrfS8Dt02Wjh/4k lOQ4vDmSw405mQUBi63cYgnSUWpJtt+teJaZqPMTwqOmn1JKIt7wQmk6OwygUSGdZv eqHa1Byf+Z8vJaMzdQVfSmmYH1k8aND/0+TL9FzdM4vhIUxmHuUmjWlyiDHr2OZmSC YIazp8L4W3XROp/Uzu1jJZ2Wmx2mYsX+qnIHHZz0XfHZhB9D8OVt/d5pzwh+SVRtjZ 3htOGEzd/cx7/4EST9I2esaENRj1+cm8ZfdnVD/P/K8YJT3gJ06l3WRF3+7MnNd2vS IhcmDb0XMzXyQ== Message-ID: <9edcabc6-bfaa-48ea-ab59-54180d6c62c7@kernel.org> Date: Wed, 22 Jan 2025 14:27:42 +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, niuzhiguo84@gmail.com, ke.wang@unisoc.com, Hao_hao.Wang@unisoc.com Subject: Re: [PATCH] f2fs: fix to avoid changing 'check only' behaior of recovery To: Zhiguo Niu , jaegeuk@kernel.org References: <1737425741-3004-1-git-send-email-zhiguo.niu@unisoc.com> Content-Language: en-US From: Chao Yu In-Reply-To: <1737425741-3004-1-git-send-email-zhiguo.niu@unisoc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/21/25 10:15, Zhiguo Niu wrote: > The following two 'check only recovery' processes are very dependent on > the return value of f2fs_recover_fsync_data, especially when the return > value is greater than 0. > 1. when device has readonly mode, shown as commit > 23738e74472f ("f2fs: fix to restrict mount condition on readonly block device") > 2. mount optiont NORECOVERY or DISABLE_ROLL_FORWARD is set, shown as commit > 6781eabba1bd ("f2fs: give -EINVAL for norecovery and rw mount") > > However, commit c426d99127b1 ("f2fs: Check write pointer consistency of open zones") > will change the return value unexpectedly, thereby changing the caller's behavior > > This patch let the f2fs_recover_fsync_data return correct value,and not do > f2fs_check_and_fix_write_pointer when the device is read-only. > > Fixes: c426d99127b1 ("f2fs: Check write pointer consistency of open zones") > Signed-off-by: Zhiguo Niu Reviewed-by: Chao Yu Thanks,