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: /JPk4w9q+uD326Eg5MAxXB151YeucMdTuitM7xijoGbG40sl7zzlSvVySTgra45duQuAy/nzeU
 0CdSFH5GDY/DNn6brLg80/nK4HHXoBeWywU+ca8prufZiL0BJpk84YbfKnhJ8ERRdsA0tPQ71U
 3clI/yNkGFFjbtU3+eLh8/dv/ZYpvLRzQLahxX99yl19xMtwFE6iMritKvqGpIAkPpasB4+wt2
 QCKNLKEyQ7rZDb7xFgtINL/SuAjRJG0bOgz2+RthjxGVHCK8UytbVOM2xtDJKSLPoSw9cbeOBA
 Doo=
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:36:32 +0000
Message-ID: <CY4PR04MB37514386D6A94A04F66EFF1DE7520@CY4PR04MB3751.namprd04.prod.outlook.com>
References: <20200827135018.63644-1-niklas.cassel@wdc.com>
 <CY4PR04MB3751526DC5833902749EBE48E7520@CY4PR04MB3751.namprd04.prod.outlook.com>
 <20200828072253.GA1331347@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: 14376990-ff66-4e79-8b20-08d84b2515a7
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2020 07:36:32.0420
 (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: 86n7rzOX0fjs1vp4jNEfAk08v1vzhyc5kClQfN00LzoIbbL9M+ZaBreuQ9UAEqiOL+FOTPaLRbx5KU0uQ4/4lw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR04MB1225
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: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, struct =
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 descr=
ibed in=0A=
>> the standards. That is, does finishing an empty zone necessarilly imply =
a=0A=
>> temporary transition through imp open ? Which you are assuming is a yes =
here.=0A=
>> Personally, I would say that is not necessary, but no strong feeling eit=
her 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 zone =
to=0A=
have a Zone Condition of EXPLICITLY OPENED or IMPLICITLY OPENED before a fi=
nish=0A=
zone operation is performed. If a zone with a Zone Condition of EMPTY or CL=
OSED=0A=
is specified for a finish zone operation, prior to processing the finish zo=
ne=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 section.=
=0A=
So this is not the same as ZNS.=0A=
=0A=
As Niklas mentioned, nullblk tends to follow more ZBC than ZNS, so the code=
 is=0A=
correct in this respect. We could also lean toward ZNS on this one. I perso=
nally=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=
Damien Le Moal=0A=
Western Digital Research=0A=