From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38511) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aW9BZ-0004jD-4h for qemu-devel@nongnu.org; Wed, 17 Feb 2016 15:58:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aW9BR-0003yL-HX for qemu-devel@nongnu.org; Wed, 17 Feb 2016 15:58:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33009) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aW9BR-0003yH-9b for qemu-devel@nongnu.org; Wed, 17 Feb 2016 15:58:49 -0500 References: <1455732653-3106-1-git-send-email-den@openvz.org> From: Eric Blake Message-ID: <56C4DF07.9020806@redhat.com> Date: Wed, 17 Feb 2016 13:58:47 -0700 MIME-Version: 1.0 In-Reply-To: <1455732653-3106-1-git-send-email-den@openvz.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NAbB7LsB7vDqqQDmP8BbqjlWh7lgrk1UJ" Subject: Re: [Qemu-devel] [RFC 1/1] nbd (specification): add NBD_CMD_WRITE_ZEROES command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Denis V. Lunev" Cc: nbd-general@lists.sourceforge.net, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NAbB7LsB7vDqqQDmP8BbqjlWh7lgrk1UJ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/17/2016 11:10 AM, Denis V. Lunev wrote: > This patch proposes a new command to reduce the amount of data passed > through the wire when it is known that the data is all zeroes. This > functionality is generally useful for mirroring or backup operations. >=20 > Currently available NBD_CMD_TRIM command can not be used as the > specification explicitely says that "a client MUST NOT make any s/explicitely/explicitly/ > assumptions about the contents of the export affected by this > [NBD_CMD_TRIM] command, until overwriting it again with `NBD_CMD_WRITE`= " >=20 > Particular use case could be the following: >=20 > QEMU project uses own implementation of NBD server to transfer data > in between different instances of QEMU. Typically we tranfer VM virtual= s/tranfer/transfer/ > disks over this channel. VM virtual disks are sparse and thus the > efficiency of backup and mirroring operations could be improved a lot. >=20 > Signed-off-by: Denis V. Lunev > --- > doc/proto.md | 7 +++++++ > 1 file changed, 7 insertions(+) >=20 > diff --git a/doc/proto.md b/doc/proto.md > index 43065b7..c94751a 100644 > --- a/doc/proto.md > +++ b/doc/proto.md > @@ -241,6 +241,8 @@ immediately after the global flags field in oldstyl= e negotiation: > schedule I/O accesses as for a rotational medium > - bit 5, `NBD_FLAG_SEND_TRIM`; should be set to 1 if the server suppor= ts > `NBD_CMD_TRIM` commands > +- bit 6, `NBD_FLAG_SEND_WRITE_ZEROES`; should be set to 1 if the serve= r > + supports `NBD_CMD_WRITE_ZEROES` commands > =20 > ##### Client flags > =20 > @@ -446,6 +448,11 @@ The following request types exist: > about the contents of the export affected by this command, until > overwriting it again with `NBD_CMD_WRITE`. > =20 > +* `NBD_CMD_WRITE_ZEROES` (6) > + > + A request to write zeroes. The command is functional equivalent of= > + the NBD_WRITE_COMMAND but without payload sent through the channel= =2E This lets us push holes during writes. Do we have the converse operation, that is, an easy way to query if a block of data will read as all zeroes, and therefore the client can bypass reading that portion of the disk (in other words, an equivalent to lseek(SEEK_HOLE/SEEK_DATA))? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --NAbB7LsB7vDqqQDmP8BbqjlWh7lgrk1UJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWxN8HAAoJEKeha0olJ0NqofoH/RdkuirgZsomRkfuxovsoNxs f0SrjwzvyNleJ9D1E+qWwbALyotcNSxImN4Hq7RRyTttEJQVWRfmdR0GL599lV35 G5ooADMCqDhj0HAwoo1geKEHlfBUisAwSpeTyx9fkHnx1FV3pCvir6zxOzButitA eG9oS1uIFCFQiUhDsaodD/MV8IV+l/KAN/q0W60oZEgEq7w5vqjcbM7SZRJJ1v22 Viz0pRI72pK2NEzSQhQa9e591flH4PWWR7jDBKnovoyaXuPxwH50ovV3e3eZetYw ig2rkLSrNdFmQn+8UGKZnN9IwQTOqJSSE9eTkpfQTnjvuRQSLfa+eKJh36A6NZw= =uP5l -----END PGP SIGNATURE----- --NAbB7LsB7vDqqQDmP8BbqjlWh7lgrk1UJ--