Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: Wtr0Cxx25HBg7a9+lh73Lz3e79+MO1O6xG7IVaMHau8poNwxsHHbAhhig0k7mUqjOwgpprPbt3
 PiuFu3CkRNhrnAzdmZ0EA59aFIl1sHavoNFyjlYOVM7c7XJ+EJ81Pph0yqUwXjOEB5o8rmpSPs
 CEAhgacUc8kVPY0NHQftC0c/sdVM3p2GfPCS7AF+KFcllzF+czL/MNnbkry8r9Jp18Toz7wFLR
 wzkf/wUqIumdcLXnqDuglmeNzMFn6+E/yC7LN/LZaNHkTG4ztBMgvyKyA8gMcSXo5ygxUrqGzh
 sxA=
From:   Damien Le Moal <Damien.LeMoal@wdc.com>
To:     Klaus Jensen <its@irrelevant.dk>
CC:     Niklas Cassel <Niklas.Cassel@wdc.com>,
        Jens Axboe <axboe@kernel.dk>,
        Johannes Thumshirn <Johannes.Thumshirn@wdc.com>,
        "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] null_blk: add support for max open/active zone limit
 for zoned devices
Thread-Topic: [PATCH v2] null_blk: add support for max open/active zone limit
 for zoned devices
Thread-Index: AQHWfHkH+20N/yg19E+BQ9ptEBewKg==
Date:   Fri, 28 Aug 2020 07:54:41 +0000
Message-ID: <CY4PR04MB375132F43CE14994D0B0773AE7520@CY4PR04MB3751.namprd04.prod.outlook.com>
References: <20200827135018.63644-1-niklas.cassel@wdc.com>
 <CY4PR04MB3751526DC5833902749EBE48E7520@CY4PR04MB3751.namprd04.prod.outlook.com>
 <20200828072253.GA1331347@apples.localdomain>
 <CY4PR04MB37514386D6A94A04F66EFF1DE7520@CY4PR04MB3751.namprd04.prod.outlook.com>
 <20200828074728.GA1343822@apples.localdomain>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 010e60d2-855b-4021-1a83-08d84b279f1d
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2020 07:54:41.6988
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 4TxuTx1JB9cI2zr+4XssSuTOsxn9UAuDKzxCirJybO9fBx80llPG+2bk/EBh7/iE4I/NyhS5mf/wXw45CrqMRg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR04MB3749
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2020/08/28 16:47, Klaus Jensen wrote:=0A=
> On Aug 28 07:36, Damien Le Moal wrote:=0A=
>> On 2020/08/28 16:23, Klaus Jensen wrote:=0A=
>>> On Aug 28 07:06, Damien Le Moal wrote:=0A=
>>>> On 2020/08/27 22:50, Niklas Cassel wrote:=0A=
>>>>> +static blk_status_t null_finish_zone(struct nullb_device *dev, struc=
t blk_zone *zone)=0A=
>>>>> +{=0A=
>>>>> +	if (zone->type =3D=3D BLK_ZONE_TYPE_CONVENTIONAL)=0A=
>>>>> +		return BLK_STS_IOERR;=0A=
>>>>> +=0A=
>>>>> +	switch (zone->cond) {=0A=
>>>>> +	case BLK_ZONE_COND_FULL:=0A=
>>>>> +		/* finish operation on full is not an error */=0A=
>>>>> +		return BLK_STS_OK;=0A=
>>>>> +	case BLK_ZONE_COND_EMPTY:=0A=
>>>>> +		if (!null_manage_zone_resources(dev, zone))=0A=
>>>>=0A=
>>>> OK. So you are hitting a fuzzy case here that is not actually well des=
cribed in=0A=
>>>> the standards. That is, does finishing an empty zone necessarilly impl=
y a=0A=
>>>> temporary transition through imp open ? Which you are assuming is a ye=
s here.=0A=
>>>> Personally, I would say that is not necessary, but no strong feeling e=
ither way.=0A=
>>>>=0A=
>>>=0A=
>>> For ZNS, the spec is pretty clear that ZSE to ZSF is a legal direct=0A=
>>> transition. So I don't think the transition should be allowed to fail=
=0A=
>>> due to a lack of resources.=0A=
>>=0A=
>> I had a doubt and checked again ZBC & ZAC. I section 4.4.3.2.4 it says:=
=0A=
>>=0A=
>> The Zone Condition state machine (see 4.4.3.5) requires the specified zo=
ne to=0A=
>> have a Zone Condition of EXPLICITLY OPENED or IMPLICITLY OPENED before a=
 finish=0A=
>> zone operation is performed. If a zone with a Zone Condition of EMPTY or=
 CLOSED=0A=
>> is specified for a finish zone operation, prior to processing the finish=
 zone=0A=
>> operation, then the Zone Condition state machine requires that:=0A=
>> a) a manage open zone resources operation (see 4.4.3.2.6) be performed; =
and=0A=
>> b) the Zone Condition becomes IMPLICITLY OPENED.=0A=
>>=0A=
>> And section 5.3 describing the zone finish command points to this sectio=
n.=0A=
>> So this is not the same as ZNS.=0A=
>>=0A=
>> As Niklas mentioned, nullblk tends to follow more ZBC than ZNS, so the c=
ode is=0A=
>> correct in this respect. We could also lean toward ZNS on this one. I pe=
rsonally=0A=
>>  have no strong opinion either way since there is not real good reasons =
for=0A=
>> finishing an empty zone that I can think of.=0A=
>>=0A=
>>=0A=
> =0A=
> Alrighty then; thanks for looking it up! I won't fight for the ZNS=0A=
> behavior then :)=0A=
=0A=
If it becomes a problem, we could add another option to force one way or th=
e=0A=
other, something like "zone_specs=3Dzbc" or "zone_specs=3Dzns". That actual=
ly may=0A=
prove useful for testing file systems etc.=0A=
=0A=
=0A=
-- =0A=
Damien Le Moal=0A=
Western Digital Research=0A=