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 3BDD9126C02 for ; Mon, 15 Dec 2025 01:49:55 +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=1765763396; cv=none; b=dCfQM4G9xRrnbfV5SNfrwEX6XdkAhA+XWIGeo+FI1kQ17kOOkKd0Ylp/qs1Ek+PF7Ltm6Br2Ph2QHzVRdZKcycZS9RatdTVNBmdvqAkv3bihgyKN6A+nhU9v1B2EqCcYRV4nIZFnyiuvjy1HFB4Ql5RLKe/VmAO/UEViV6goBWY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765763396; c=relaxed/simple; bh=7cP/acxYmB/cgIlU1eAt+cqS8ncm6LYZEGysGflX8jU=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=k30FR/FpydGmP8I8UI+FXP6B4P2ZovcHvkj79QhqyeKbTHOsS5E0N8ho8ojZUgVjK5nPviijZW+DHKSt3qkIk3w34/UFot6YbsaEacrLHLCfUCFosXgwwK+yNsalzJ9vcJ3Rn17FEdJclIUgLKGL+vhFQbSabtlxCsmMWBvYhU4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UPbWZpSG; 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="UPbWZpSG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9739BC4CEF1; Mon, 15 Dec 2025 01:49:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1765763395; bh=7cP/acxYmB/cgIlU1eAt+cqS8ncm6LYZEGysGflX8jU=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=UPbWZpSG+0Vw1QcxFkE79hzhmOW6sA/4o1sVFVq5pDg4hntjKhknL5owq4DoeCycj /FMY8MWQj/JOlZgMeh0VhQ3O2YgDiYWXoNtVbnwaWGu8I+P61ekQlK8LOTOmJQoU/2 XAK3PerAhdo2Bg3+OR1H2/4aMXOCriCGX5bTrzfEHipl1fY0R/tcVP2WFBqspbE8h5 vSWQo5PaezcJ/TLKzcx2pQ0jD504ZWYgRKP21A1lFqyB5c5oBogoVObSPxN4Tu81Jc T2qNE28HsCEep3zDmB9SsgB089SYtGZJMO3HujQoMRFHLkTOTmUHQYu/bqlXU6WlzQ ImNcIyuJ340Mw== Message-ID: <2a330404-8518-4891-8ec9-dfe18074780a@kernel.org> Date: Mon, 15 Dec 2025 09:49:52 +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 Subject: Re: [PATCH v1] f2fs: improve check for enough free sections To: Joanne Chang , Jaegeuk Kim References: <20251212084034.2878836-1-joannechien@google.com> Content-Language: en-US From: Chao Yu In-Reply-To: <20251212084034.2878836-1-joannechien@google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12/12/25 16:40, Joanne Chang wrote: > The check for enough sections in segment.h has the following issues: > > 1. has_not_enough_free_secs() should return "enough secs" when "free_secs >> = upper_secs", not just structly greater. Conversely, it should only > return "not enough secs" when "free_secs < lower_secs", not when they are > equal. This accounts for the possibility that blocks can fit within > curseg without requiring an additional free section. > > 2. __get_secs_required() currently separates the needed space to section > and block parts, checking them against free sections and curseg, > respectively. This does not consider the case where curseg cannot hold > the whole block part, but excess free sections beyond the section part > can accommodate some of the block part. > > 3. has_curseg_enough_space() only checks CURSEG_HOT_DATA for dentry > blocks, but when active_logs=6, they may be placed in WARM and COLD > sections. Also, the current logic does not consider that dentry and data > blocks can be put in the same section when active_logs=2 or 6. > > This patch modifies the three functions to address the above issues: > > 1. Rename has_curseg_enough_space() to get_additional_blocks_required(). > Calculate the minimum node, dentry, and data blocks curseg can > accommodate. Then subtract these from the total required blocks of > respective type to determine the worst-case number of blocks that must > be placed in free sections. > > 2. In __get_secs_required(), get the number of blocks needing new > sections from the new get_additional_blocks_required(). Return the upper > bound of necessary free sections for these blocks. For active_logs=2 or > 6, dentry blocks are combined with data blocks. > > 3. In has_not_enough_free_secs(), get the required sections from > __get_secs_required(), and return “not enough secs” if “free_secs < > required_secs”. > > Signed-off-by: Joanne Chang Reviewed-by: Chao Yu Thanks,