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 we also have been working on for several months (see
patches additions from today). We just have a couple of use cases where
append is not required and I would like to make sure that they are
supported.
At the end of the day, the only thing I have disagreed on is that the
NVMe driver rejects ZNS SSDs that do not support append, as opposed to
doing this instead when an in-kernel user wants to utilize the drive
(e.g., formatting a FS with zoned support) This would allow _today_
ioctl() passthru to work for normal writes.
I still believe the above would be a more inclusive solution with the
current ZNS specification, but I can see that the general consensus is
different.
So we will go back, apply the feedback that we got and return with an
approach that better fits the ecosystem.
Another approach, is to use SPDK, and bypass the Linux kernel. This
might even be an advantage, your customers does not have to wait on
the Linux distribution being released with a long term release, before
they can even get started and deploy in volume. I.e., they will
actually get faster to market, and your company will be able to sell
more drives.
I think I will refrain from discussing our business strategy on an open
mailing list. Appreciate the feedback though. Very insightful.
Thanks,
Javier
