From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5E581C4332F for ; Wed, 4 Jan 2023 08:00:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1672819238; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=yRQRdSINzhQXExBP2Sg0W1iIEGPCt3PT5Bw/66VPVW0=; b=FsLiHKpgmZ2zoeJxQi3wgqZUG+hIE1q+MLncEik0ANMs9Cz7sxpkG+CMd89DRvruDGyH7A iXFlMjHLOjOv4s/1KlO2StpK6Kbb5aYPdFSj3vBXrh90iTGAGPH+QEOEerF+QXwSuqFZ7r F3JFVJ9GkGxylpOrETpeqkLv0HYVh20= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-327-iQTohdAANwqKTOTyBowjtw-1; Wed, 04 Jan 2023 03:00:37 -0500 X-MC-Unique: iQTohdAANwqKTOTyBowjtw-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2775185C069; Wed, 4 Jan 2023 08:00:35 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (unknown [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 819A949BB6A; Wed, 4 Jan 2023 08:00:32 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 72EFE1946589; Wed, 4 Jan 2023 08:00:32 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 5FC6B1946587 for ; Wed, 4 Jan 2023 05:47:15 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 4EDBB40C115E; Wed, 4 Jan 2023 05:47:15 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast06.extmail.prod.ext.rdu2.redhat.com [10.11.55.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4490640C1141 for ; Wed, 4 Jan 2023 05:47:15 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1C52718A6460 for ; Wed, 4 Jan 2023 05:47:15 +0000 (UTC) Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-16-XN2-08C2OJydOtAYgJH_ew-1; Wed, 04 Jan 2023 00:47:13 -0500 X-MC-Unique: XN2-08C2OJydOtAYgJH_ew-1 Received: from pps.filterd (m0279867.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3044pYt0007965; Wed, 4 Jan 2023 05:29:45 GMT Received: from nalasppmta04.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3mvsvf8vuk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 04 Jan 2023 05:29:45 +0000 Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA04.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 3045TiKn012309 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 4 Jan 2023 05:29:44 GMT Received: from [10.253.73.183] (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.36; Tue, 3 Jan 2023 21:29:40 -0800 Message-ID: <3b4e4a73-7870-750a-8a39-58735843b0aa@quicinc.com> Date: Wed, 4 Jan 2023 13:29:37 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.0.3 To: Pankaj Raghav , , , , , References: <20220923173618.6899-1-p.raghav@samsung.com> From: Can Guo In-Reply-To: <20220923173618.6899-1-p.raghav@samsung.com> X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01a.na.qualcomm.com (10.47.209.196) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: UaXsZWJLRt9HgnTweGXi7pOHqiiwdyWD X-Proofpoint-ORIG-GUID: UaXsZWJLRt9HgnTweGXi7pOHqiiwdyWD X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2023-01-04_02,2023-01-03_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 mlxlogscore=999 spamscore=0 impostorscore=0 lowpriorityscore=0 malwarescore=0 phishscore=0 mlxscore=0 bulkscore=0 clxscore=1011 suspectscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2301040045 X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Mailman-Approved-At: Wed, 04 Jan 2023 08:00:30 +0000 Subject: Re: [dm-devel] [PATCH v15 00/13] support zoned block devices with non-power-of-2 zone sizes X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bvanassche@acm.org, pankydev8@gmail.com, gost.dev@samsung.com, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, linux-block@vger.kernel.org, dm-devel@redhat.com, Johannes.Thumshirn@wdc.com, jaegeuk@kernel.org, matias.bjorling@wdc.com Errors-To: dm-devel-bounces@redhat.com Sender: "dm-devel" X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: multipart/mixed; boundary="===============2953017245163883128==" --===============2953017245163883128== Content-Type: multipart/alternative; boundary="------------BOBzQrHqhhri7rEaUfa0nJHg" Content-Language: en-US --------------BOBzQrHqhhri7rEaUfa0nJHg Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Hi Pankaj, On 9/24/2022 1:36 AM, Pankaj Raghav wrote: > Hi Jens, > Please consider this patch series for the 6.1 release. > > - Background and Motivation: > > The zone storage implementation in Linux, introduced since v4.10, first > targetted SMR drives which have a power of 2 (po2) zone size alignment > requirement. The po2 zone size was further imposed implicitly by the > block layer's blk_queue_chunk_sectors(), used to prevent IO merging > across chunks beyond the specified size, since v3.16 through commit > 762380ad9322 ("block: add notion of a chunk size for request merging"). > But this same general block layer po2 requirement for blk_queue_chunk_sectors() > was removed on v5.10 through commit 07d098e6bbad ("block: allow 'chunk_sectors' > to be non-power-of-2"). > > NAND, which is the media used in newer zoned storage devices, does not > naturally align to po2. In these devices, zone capacity(cap) is not the > same as the po2 zone size. When the zone cap != zone size, then unmapped > LBAs are introduced to cover the space between the zone cap and zone size. > po2 requirement does not make sense for these type of zone storage devices. > This patch series aims to remove these unmapped LBAs for zoned devices when > zone cap is npo2. This is done by relaxing the po2 zone size constraint > in the kernel and allowing zoned device with npo2 zone sizes if zone cap > == zone size. I came across function sd_zbc_check_capacity() in sd_zbc.c, it still errors out in case of npo2. I don't see this series touching sd_zbc.c. Is there plan or existing change to relax this check? if(!*is_power_of_2* (*zone_blocks* )){ *sd_printk* (*KERN_ERR* ,sdkp, "Zone size %llu is not a power of two.\n", *zone_blocks* ); return-*EINVAL* ; } Thanks. Regards, Can Guo. --------------BOBzQrHqhhri7rEaUfa0nJHg Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mx0a-0031df01.pphosted.com id 3044pYt0007965

Hi Pankaj,

On 9/24/2022 1:36 AM, Pankaj Raghav wrote:
Hi Jens,
  Please consider this patch series for the 6.1 release.

- Background and Motivation:

The zone storage implementation in Linux, introduced since v4.10, first
targetted SMR drives which have a power of 2 (po2) zone size alignment
requirement. The po2 zone size was further imposed implicitly by the
block layer's blk_queue_chunk_sectors(), used to prevent IO merging
across chunks beyond the specified size, since v3.16 through commit
762380ad9322 ("block: add notion of a chunk size for request merging").
But this same general block layer po2 requirement for blk_queue_chunk_secto=
rs()
was removed on v5.10 through commit 07d098e6bbad ("block: allow 'chunk_sect=
ors'
to be non-power-of-2").

NAND, which is the media used in newer zoned storage devices, does not
naturally align to po2. In these devices, zone capacity(cap) is not the
same as the po2 zone size. When the zone cap !=3D zone size, then unmapped
LBAs are introduced to cover the space between the zone cap and zone size.
po2 requirement does not make sense for these type of zone storage devices.
This patch series aims to remove these unmapped LBAs for zoned devices when
zone cap is npo2. This is done by relaxing the po2 zone size constraint
in the kernel and allowing zoned device with npo2 zone sizes if zone cap
=3D=3D zone size.

I came across function sd_zbc_check_capacity() in sd_zbc.c, it still errors out in case of npo2.

I don't see this series touching sd_zbc.c. Is there plan or existing change to relax this check?


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 if (!is_power_of_2(zone_blocks)) {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sd_printk(KERN_ERR, sdkp,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 "Zone size %llu is not a power of two.\n",

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 zone_blocks);

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return -EINVAL;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 }


Thanks.

Regards,

Can Guo.


    

  


--------------BOBzQrHqhhri7rEaUfa0nJHg--

--===============2953017245163883128==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel

--===============2953017245163883128==--