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: lmmBmfUOval16CTT4O4qyuLEKa1/vpnl/lrdqaG6i7j6xRningeLYDu9OqSQgh2sqToylvfk5U
 Atjc9SoaHpSgGxSGkDf1D3k/EEjVjMpqKQMr11yROSdboyD0+AcCJzgMimlnRrb8DUR/8pbWRr
 zGMFwuSpksL1YVzyPM9WsIF+XasOjYRyAa2bMvelsAY6BdLl2uhynf8UNjGzHsdiuAtJjEA46l
 W01F4wv1CeGy5hM2UHZSMnFK9p/j+YEBUVmMStVpWAzIbmVGhzW4hjUDWW2rCYa/RXW9sEW7gA
 Bio=
From:   Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
To:     Niklas Cassel <Niklas.Cassel@wdc.com>
CC:     Jonathan Corbet <corbet@lwn.net>, Jens Axboe <axboe@kernel.dk>,
        Keith Busch <kbusch@kernel.org>,
        Christoph Hellwig <hch@lst.de>,
        Sagi Grimberg <sagi@grimberg.me>,
        "James E.J. Bottomley" <jejb@linux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@oracle.com>,
        =?iso-8859-1?Q?Javier_Gonz=E1lez?= <javier@javigon.com>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
        "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
        "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH v2 1/2] block: add max_open_zones to blk-sysfs
Thread-Topic: [PATCH v2 1/2] block: add max_open_zones to blk-sysfs
Thread-Index: AQHWUJ1laLSAJw11LUObxsrvIlcW1g==
Date:   Fri, 3 Jul 2020 12:09:29 +0000
Message-ID: <SN4PR0401MB359801D165A0B9882B43B3719B6A0@SN4PR0401MB3598.namprd04.prod.outlook.com>
References: <20200702181922.24190-1-niklas.cassel@wdc.com>
 <20200702181922.24190-2-niklas.cassel@wdc.com>
 <SN4PR0401MB359886C77E3711DAF16D9B9F9B6A0@SN4PR0401MB3598.namprd04.prod.outlook.com>
 <20200703092353.GA33841@localhost.localdomain>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3dfaa944-a9a9-4990-bf38-08d81f49f070
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2020 12:09:29.9051
 (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: 62akM7fmIZD5H6031culOFUlMnyLDYsMJXvB+doiJDaU5oSRad7m83vHtkqWbe/o1wkKUOhzDj+HKuifAJRY7ZKM2EgTB+aN35VU+UZGHOM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR04MB4461
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 03/07/2020 11:23, Niklas Cassel wrote:=0A=
> On Fri, Jul 03, 2020 at 08:22:45AM +0000, Johannes Thumshirn wrote:=0A=
>> On 02/07/2020 20:20, Niklas Cassel wrote:=0A=
>>> Documentation/block/queue-sysfs.rst |  7 +++++++=0A=
>>>  block/blk-sysfs.c                   | 15 +++++++++++++++=0A=
>>>  drivers/nvme/host/zns.c             |  1 +=0A=
>>>  drivers/scsi/sd_zbc.c               |  4 ++++=0A=
>>>  include/linux/blkdev.h              | 16 ++++++++++++++++=0A=
>>>  5 files changed, 43 insertions(+)=0A=
>>=0A=
>> Sorry I haven't noticed before, but you forgot null_blk.=0A=
> =0A=
> Hello Johannes,=0A=
> =0A=
> Actually, I haven't forgotten about null_blk :)=0A=
> =0A=
> The problem with null_blk is that, compared to these simple patches that=
=0A=
> simply exposes the Max Open Zones/Max Active Zones, null_blk additionally=
=0A=
> has to keep track of all the zone accounting, and give an error if any=0A=
> of these limits are exceeded.=0A=
> =0A=
> null_blk right now follows neither the ZBC nor the ZNS specification=0A=
> (even though it is almost compliant with ZBC). However, since null_blk=0A=
> is really great to test with, we want it to support Max Active Zones,=0A=
> even if that concept does not exist in the ZBC standard.=0A=
> =0A=
> To add to the problem, open() does not work exactly the same in ZBC and=
=0A=
> ZNS. In ZBC, the device always tries to close an implicit zone to make=0A=
> room for an explicit zone. In ZNS, a controller that doesn't do this is=
=0A=
> fully compliant with the spec.=0A=
> =0A=
> So now for null_blk, you have things like zones being implicit closed whe=
n=0A=
> a new zone is opened. And now we will have an additional limit (Max Activ=
e=0A=
> Zones), that we need to consider before we can even try to close a zone.=
=0A=
> =0A=
> =0A=
> I've spent a couple of days trying to implement this already, and I think=
=0A=
> that I have a way forward. However, considering that vacations are coming=
=0A=
> up, and that I have a bunch of other stuff that I need to do before then,=
=0A=
> I'm not 100% sure that I will be able to finish it in time for the coming=
=0A=
> merge window.=0A=
> =0A=
> Therefore, I was hoping that we could merge this series as is, and I will=
=0A=
> send out the null_blk changes when they are ready, which might or might=
=0A=
> not make it for this merge window.=0A=
=0A=
No problem, I'm just working on MOR support for zonefs and though about how=
=0A=
I'm going to test it. This is where I've noticed null_blk doesn't really =
=0A=
expose a config knob for MOR. I can do some temporary hacks to test my chan=
ges=0A=
and wait for your's to materialize. =0A=
=0A=
=0A=
> In the meantime, MAR/MOR properties for null_blk will be exposed as 0,=0A=
> which means "no limit". (Which is the case when a zoned block device driv=
er=0A=
> doesn't do an explicit call to blk_queue_max_{open,active}_zones()).=0A=
=0A=