nvme: report capacity 0 for non supported ZNS SSDs

[Javier Gonzalez]

On 02.11.2020 19:58, hch at lst.de wrote:
>On Mon, Nov 02, 2020 at 10:33:55AM -0800, Keith Busch wrote:
>> I can see this going one of two ways:
>>
>>  a) Set up the existing controller character device with a generic
>>     disk-less request_queue to the IO queues accepting IO commands to
>>     arbitrary NSIDs.
>>
>>  b) Each namespace that can't be supported gets their own character
>>     device.
>>
>> I'm leaning toward option "a". While it doesn't create handles to unique
>> namespaces, it has more resilience to potentially future changes. And I
>> recall the target side had a potential use for that, too.
>
>The problem with a) is that it can't be used to give users or groups
>access to just one namespaces, so it causes a real access control
>nightmare.  The problem with b) is that now applications will break
>when we add support for new command sets or features.  I think
>
>  c) Each namespace gets its own character device, period.
>
>is the only sensible option.

This sounds reasonable. We have been back and forth on a patchset with
async passthru using io_uring. I believe this can help with some of the
questions we are preparing for a RFC.

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.

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.

Javier