That makes sense. We are generally paying a high price for
implementing in-order interfaces over out-of-order communication
channels (e.g. TCP buffers) and append() seems to be a much more
lightweight solution.

On Fri, Jun 19, 2020 at 11:25 AM Matias Bjørling [off-list ref] wrote:

On 19/06/2020 20.17, Heiner Litz wrote:

quoted

quoted

On Fri, Jun 19, 2020 at 11:08:26AM -0700, Heiner Litz wrote:

quoted

Hi Matias,
no, I am rather saying that the Linux kernel has a deficit or at least
is not a good fit for ZNS because it cannot enforce in-order delivery.

FYI, the nvme protocol can't even enforce in-order delivery, so calling
out linux for this is a moot point.

How does it work in SPDK then? I had understood that SPDK supported
QD>1 for ZNS devices.

It doesn't. Out of order delivery is not guaranteed in NVMe.

quoted

I am not saying that Linux is the only problem. The fact remains that
out of order delivery is not a good fit for an interface that requires
sequential writes.

That why zone append was introduced in ZNS. It removes this constraint,
and makes it such that any process (or host) can write to a specific
zone. It's neat! That is why the command was introduced.

It is not only Linux specific - it applies to everyone that wants to use
it. It is solving a fundamental distributed system problem, as it
removes the need for fine-grained coordinating between process or host.
It allows the SSD to coordinate data placement, which historically has
been done by the host. It is awesome!

quoted

quoted

quoted

The requirement of sequential writes basically imposes this
requirement. Append essentially a Linux specific fix on the ZNS level
and that enforcing ordering would be a cleaner way to enable QD>1.