On 02/08/2018 09:28 AM, Edgar Kaziakhmedov wrote:

We've got a potential problem.  Unless you have out-of-band communication of the maximum NBD_CMD_WRITE_ZEROES sizing (or if the NBD protocol is enhanced to advertise that as an additional piece of block size information during NBD_OPT_GO), then a client CANNOT assume that the server will accept a request this large. We MIGHT get lucky if all existing servers that accept WRITE_ZEROES requests either act on large requests or reply with EINVAL but do not outright drop the connection (which is different from servers that DO outright drop the connection for an NBD_CMD_WRITE larger than 32M).  But I don't know if that's how all servers behave, so sending a too-large WRITE_ZEROES request may have the unintended consequence of killing the connection.
Actually, I do not understand why current NBD servers shouldn't accept such large requests, because most servers should apply some optimizations avoiding direct filling with zeroes.

Just because a server CAN optimize doesn't mean that it is REQUIRED to optimize. You cannot make assumptions that a server will be happy with a larger request, merely because less data was sent over the wire, because the server may still have to allocate memory locally to perform the request.

As for block-mirroring over NBD, it works fine with QEMU server implementation and isn't it the main application?

Yes, qemu-to-qemu interoperating as efficiently as possible is nice; but I'm worried about qemu-to-other interoperating as well. The point of a public specification is to avoid one-way silos, so that you CAN mix-and-match a server from one implementation with a client from another, rather than being forced to use qemu as the server when qemu is the client. Note that portability can include hand-shaking to fall back to the least-common denominator, rather than requiring both sides to always understand all extensions; but the important part is that neither party should make assumptions about the other side without using the spec as their guide.

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Reply via email to