Re: nvme: report capacity 0 for non supported ZNS SSDs

From: Javier Gonzalez <javier@javigon.com>
To: "hch@lst.de" <hch@lst.de>
Cc: Keith Busch <kbusch@kernel.org>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"sagi@grimberg.me" <sagi@grimberg.me>,
	"axboe@kernel.dk" <axboe@kernel.dk>,
	"joshi.k@samsung.com" <joshi.k@samsung.com>,
	"Klaus B. Jensen" <k.jensen@samsung.com>,
	"Niklas.Cassel@wdc.com" <Niklas.Cassel@wdc.com>
Subject: Re: nvme: report capacity 0 for non supported ZNS SSDs
Date: Tue, 3 Nov 2020 15:10:19 +0100	[thread overview]
Message-ID: <20201103141019.5eomaxs4qn4ezaeh@MacBook-Pro.localdomain> (raw)
In-Reply-To: <20201103090628.GA15656@lst.de>

On 03.11.2020 10:06, hch@lst.de wrote:
>On Mon, Nov 02, 2020 at 10:24:05PM +0100, Javier Gonzalez wrote:
>> If I understand correctly, the model would be that a namespace will
>> always have (i) a character device associated where I/O is always allowed
>> through user formed commands, and if the namespace has full support in
>> the kernel (ii) a block device where I/O is as it is today. In case of
>> (ii) both interfaces can be used for I/O.
>
>Yes.

Thanks for confirming.

One question here is that we are preparing a RFC for a io_uring passthru
using the block device. Based on this discussion, it seems to me that
you see this more suitable through the char device.

Does it make sense that we post this RFC using the block device? It
would be helpful to get early feedback before starting the char device.

>
>> While we work on iterations for c), do you believe it is reasonable to
>> merge a version of the current path that follows the PI convention for
>> unsupported command sets and features? I would assume that we will have
>> to convert PI to this model too when it is available.
>
>I'm rather torn.  I think the model of the zero capacity block device
>is a really, really bad one and we should haver never added it.  That
>being said, for a ZNS namespace that does not support Zone Append I
>can think of a model that actually makes sense:  expose it as a read-only
>block device, as we can actually read from it perfectly fine, and that
>would also allow ioctl access.

This is reasonable. I can re-spin this for append to become read-only
and then we work in parallel for the char device interface.

I see that this does not make much sense for the other non-supported
features in this patch (i.e., !po2 zone size and zoc). Since this is
very much like PI today, is it OK we add these the same way (capacity 0)
and then move to the char device when ready?