-----Original Message-----
From: Javier González <javier@xxxxxxxxxxx>
Sent: Wednesday, 17 June 2020 20.29
To: Matias Bjørling <mb@xxxxxxxxxxx>
Cc: Christoph Hellwig <hch@xxxxxx>; Keith Busch <Keith.Busch@xxxxxxx>;
linux-nvme@xxxxxxxxxxxxxxxxxxx; linux-block@xxxxxxxxxxxxxxx; Damien
Le Moal
<Damien.LeMoal@xxxxxxx>; Matias Bjorling <Matias.Bjorling@xxxxxxx>;
Sagi Grimberg <sagi@xxxxxxxxxxx>; Jens Axboe <axboe@xxxxxxxxx>; Hans
Holmberg <Hans.Holmberg@xxxxxxx>; Dmitry Fomichev
<Dmitry.Fomichev@xxxxxxx>; Ajay Joshi <Ajay.Joshi@xxxxxxx>; Aravind
Ramesh <Aravind.Ramesh@xxxxxxx>; Niklas Cassel
<Niklas.Cassel@xxxxxxx>; Judy Brock <judy.brock@xxxxxxxxxxx>
Subject: Re: [PATCH 5/5] nvme: support for zoned namespaces
On 17.06.2020 19:57, Matias Bjørling wrote:
>On 17/06/2020 16.42, Javier González wrote:
>>On 17.06.2020 09:43, Christoph Hellwig wrote:
>>>On Tue, Jun 16, 2020 at 12:41:42PM +0200, Javier González wrote:
>>>>On 16.06.2020 08:34, Keith Busch wrote:
>>>>>Add support for NVM Express Zoned Namespaces (ZNS) Command Set
>>>>>defined in NVM Express TP4053. Zoned namespaces are discovered
>>>>>based on their Command Set Identifier reported in the namespaces
>>>>>Namespace Identification Descriptor list. A successfully
discovered
>>>>>Zoned Namespace will be registered with the block layer as a host
>>>>>managed zoned block device with Zone Append command support. A
>>>>>namespace that does not support append is not supported by the
driver.
>>>>
>>>>Why are we enforcing the append command? Append is optional on the
>>>>current ZNS specification, so we should not make this mandatory in
>>>>the implementation. See specifics below.
>>>
>>>Because Append is the way to go and we've moved the Linux zoned
block
>>>I/O stack to required it, as should have been obvious to anyone
>>>following linux-block in the last few months. I also have to say
I'm
>>>really tired of the stupid politics tha your company started in the
>>>NVMe working group, and will say that these do not matter for Linux
>>>development at all. If you think it is worthwhile to support
devices
>>>without Zone Append you can contribute support for them on top of
>>>this series by porting the SCSI Zone Append Emulation code to NVMe.
>>>
>>>And I'm not even going to read the rest of this thread as I'm on a
>>>vacation that I badly needed because of the Samsung TWG bullshit.
>>
>>My intention is to support some Samsung ZNS devices that will not
>>enable append. I do not think this is an unreasonable thing to do.
How
>>/ why append ended up being an optional feature in the ZNS TP is
>>orthogonal to this conversation. Bullshit or not, it ends up on
>>devices that we would like to support one way or another.
>
>I do not believe any of us have said that it is unreasonable to
>support. We've only asked that you make the patches for it.
>
>All of us have communicated why Zone Append is a great addition to the
>Linux kernel. Also, as Christoph points out, this has not been a
secret
>for the past couple of months, and as Martin pointed out, have been a
>wanted feature for the past decade in the Linux community.
>
>I do want to politely point out, that you've got a very clear signal
>from the key storage maintainers. Each of them is part of the planet's
>best of the best and most well-respected software developers, that
>literally have built the storage stack that most of the world depends
>on. The storage stack that recently sent manned rockets into space.
>They each unanimously said that the Zone Append command is the right
>approach for the Linux kernel to reduce the overhead of I/O tracking
>for zoned block devices. It may be worth bringing this information to
>your engineering organization, and also potentially consider Zone
>Append support for devices that you intend to used with the Linux
>kernel storage stack.
I understand and I have never said the opposite.
Append is a great addition that
