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 <mb@xxxxxxxxxxx> wrote: > > On 19/06/2020 20.17, Heiner Litz wrote: > >> On Fri, Jun 19, 2020 at 11:08:26AM -0700, Heiner Litz wrote: > >>> 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. > > 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! > > > > >>> 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. > >
