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 A99EC362130 for ; Fri, 17 Apr 2026 07:58:50 +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=1776412730; cv=none; b=Sw8YEAx4kfKIdNBjqVdunHChCd+WuEkoPZTX89eAgm2IM7NBJYI6608yB5e1L2mxsYG9g3jJUCwSOS3oiAbJlzHij3hVK1lAY/mNcwpjRjittfslogxA/GXDKui5HcaWOEXcR+1FO8CGyG7Z1xZ0dD4ksd4N/YbECzloMXyC/oE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776412730; c=relaxed/simple; bh=mlhnpdv2cOQqDjf++vqtl0/8msZ/q+97zbd810L3RSU=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=uHOBCPBvig4RQig4Rd3R44MMEIf4Ysv+XV4MoTEfl9YCDZ6Owv4zw9GWFA25l8+Kw0h+VFkDxqBqEEgxLsk4c99NzRnooeZSxFdgSfdr61fAUR6i5abQXZapnYUY+V9ILmGzzT8YxDfIvpyct3JqnfQPx4wofyhfia6ZId1wUHo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TbsYhsWf; 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="TbsYhsWf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2E33C19425; Fri, 17 Apr 2026 07:58:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776412730; bh=mlhnpdv2cOQqDjf++vqtl0/8msZ/q+97zbd810L3RSU=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=TbsYhsWfHetB/Pzx0+1NDgHAUJWsBbiFcm/YssfrmyNDm0XpiAc1kD2XgG1vvXN8A +0eQICLsLwg3nmnCjBajG/zcggB41wCTVgjSzf0LMVUao1og93yTjB7JlkN7TxcZnK 30NzUZwdgfZXYkctQ4wvlNzCwpk2nYIy+5nPoD849Z+LrSvqO5iTLbwkvF1flvg6yi 6MmL2Ou1UMXWTtm1cEXRQ2ZJIC8u+m4WCWQ5OZK3O5vFDMXePLZxBQRoUrYWr9ZWyE PLlqMtzVKo/5xqI0fDJc9Eq3zVJkFr6noE3enANnh2DINxbvhRGo7YDCyAEDlpXRD8 fhpEfYlRRkp8g== Message-ID: <06a0e816-21fd-4a5d-9389-4be43ce63d12@kernel.org> Date: Fri, 17 Apr 2026 15:58:46 +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, qiwenjie@xiaomi.com Subject: Re: [RFC PATCH v2] f2fs: map data writes to FDP streams To: Wenjie Qi , jaegeuk@kernel.org References: <20260417035126.3886702-1-qiwenjie@xiaomi.com> Content-Language: en-US From: Chao Yu In-Reply-To: <20260417035126.3886702-1-qiwenjie@xiaomi.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/17/2026 11:51 AM, Wenjie Qi wrote: > From: Wenjie Qi > > From: Wenjie Qi > > F2FS already classifies DATA writes using its existing hot, warm and cold > temperature policy, but it only passes that intent down as a write hint. > That hint alone is not sufficient for NVMe FDP placement, because the > current NVMe command path consumes `bio->bi_write_stream` rather than > `bio->bi_write_hint` when selecting a placement ID. > > When the target block device exposes write streams, map the existing F2FS > DATA temperature classes onto stream IDs and set `bio->bi_write_stream` > for both buffered and direct writes. If the device exposes no write > streams, keep the current behavior by leaving the stream unset. > > The stream mapping is evaluated against the target block device of each > bio, so the existing per-device fallback behavior stays unchanged for > multi-device filesystems. Existing blkzoned restrictions also remain in > place. > > The mapping is intentionally small and deterministic: > > - 1 stream: hot, warm and cold all use stream 1 > - 2 streams: hot/warm use 1, cold uses 2 > - 3+ streams: hot uses 1, warm uses 2, cold uses 3 > > Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Thanks,