Dropping non-nbd lists On 8/23/19 9:34 AM, Eric Blake wrote: > While it may be counterintuitive at first, the introduction of > NBD_CMD_WRITE_ZEROES and NBD_CMD_BLOCK_STATUS has caused a performance > regression in qemu [1], when copying a sparse file. When the > destination file must contain the same contents as the source, but it > is not known in advance whether the destination started life with all > zero content, then there are cases where it is faster to request a > bulk zero of the entire device followed by writing only the portions > of the device that are to contain data, as that results in fewer I/O > transactions overall. > @@ -2015,7 +2033,10 @@ The following request types exist: > reached permanent storage, unless `NBD_CMD_FLAG_FUA` is in use. > > A client MUST NOT send a write zeroes request unless > - `NBD_FLAG_SEND_WRITE_ZEROES` was set in the transmission flags field. > + `NBD_FLAG_SEND_WRITE_ZEROES` was set in the transmission flags > + field. Additionally, a client MUST NOT send the > + `NBD_CMD_FLAG_FAST_ZERO` flag unless `NBD_FLAG_SEND_FAST_ZERO` was > + set in the transimssion flags field. Squashing in a typo fix here. > > By default, the server MAY use trimming to zero out the area, even > if it did not advertise `NBD_FLAG_SEND_TRIM`; but it MUST ensure > @@ -2025,6 +2046,28 @@ The following request types exist: > same area will not cause fragmentation or cause failure due to > insufficient space. > > + If the server advertised `NBD_FLAG_SEND_FAST_ZERO` but > + `NBD_CMD_FLAG_FAST_ZERO` is not set, then the server MUST NOT fail > + with `NBD_ENOTSUP`, even if the operation is no faster than a > + corresponding `NBD_CMD_WRITE`. Conversely, if > + `NBD_CMD_FLAG_FAST_ZERO` is set, the server MUST fail quickly with > + `NBD_ENOTSUP` unless the request can be serviced in less time than > + a corresponding `NBD_CMD_WRITE`, and SHOULD NOT alter the contents > + of the export when returning this failure. The server's > + determination of a fast request MAY depend on a number of factors, Maybe: determination of whether to fail fast rather than proceed MAY depend... > + such as whether the request was suitably aligned, on whether the > + `NBD_CMD_FLAG_NO_HOLE` flag was present, or even on whether a > + previous `NBD_CMD_TRIM` had been performed on the region. If the > + server did not advertise `NBD_FLAG_SEND_FAST_ZERO`, then it SHOULD > + NOT fail with `NBD_ENOTSUP`, regardless of the speed of servicing > + a request, and SHOULD fail with `NBD_EINVAL` if the > + `NBD_CMD_FLAG_FAST_ZERO` flag was set. A server MAY advertise > + `NBD_FLAG_SEND_FAST_ZERO` whether or not it can perform fast > + zeroing; similarly, a server SHOULD fail with `NBD_ENOTSUP` when > + the flag is set if the server cannot quickly determine in advance > + whether that request would have been fast, even if it turns out > + that the same request without the flag would be fast after all. > + > If an error occurs, the server MUST set the appropriate error code > in the error field. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature