From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51433) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWRYZ-0003Y9-Bl for qemu-devel@nongnu.org; Thu, 18 Feb 2016 11:35:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWRYU-0007Ls-Dn for qemu-devel@nongnu.org; Thu, 18 Feb 2016 11:35:55 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWRYU-0007Lb-5e for qemu-devel@nongnu.org; Thu, 18 Feb 2016 11:35:50 -0500 References: <1455732653-3106-1-git-send-email-den@openvz.org> <56C4DF07.9020806@redhat.com> <20160218091857.GA12337@rkaganb.sw.ru> From: Eric Blake Message-ID: <56C5F2E3.1090102@redhat.com> Date: Thu, 18 Feb 2016 09:35:47 -0700 MIME-Version: 1.0 In-Reply-To: <20160218091857.GA12337@rkaganb.sw.ru> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xCiNp3em6rDbgM42qm9wxbURXNeTMC5dA" 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: Roman Kagan , "Denis V. Lunev" , nbd-general@lists.sourceforge.net, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xCiNp3em6rDbgM42qm9wxbURXNeTMC5dA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/18/2016 02:18 AM, Roman Kagan wrote: > On Wed, Feb 17, 2016 at 01:58:47PM -0700, Eric Blake wrote: >> On 02/17/2016 11:10 AM, Denis V. Lunev wrote: >>> @@ -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 chann= el. >> >> 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 o= f >> the disk (in other words, an equivalent to lseek(SEEK_HOLE/SEEK_DATA))= ? >=20 > The spec doesn't have anything like that. >=20 > OTOH, unlike the write case, where you have all the information and jus= t > choose whether to send normal write or zero write, the extra round-trip= > of a separate SEEK_HOLE/SEEK_DATA request may lead to actually degradin= g > the overall throughput. >=20 > Rather it may be a better idea to add something like sparse read where > the server would, instead of sending the full length of data in the > response payload, send a smarter variable-length package with a > scatter-gather list or a bitmap of used blocks in the beginning, and le= t > the client decode it and fill the gaps with zeros. Sure, that would work too, and sounds nicer. Either way, the point is that we should strongly consider improving the NBD protocol to allow more efficient handling of sparse files, in both the push and in the pull direction. Qemu already has a desire to use both directions of improvements, but there are more programs, both clients and servers, outside of qemu, that could benefit from such protocol improvements. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --xCiNp3em6rDbgM42qm9wxbURXNeTMC5dA 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/ iQEcBAEBCAAGBQJWxfLjAAoJEKeha0olJ0Nq15sIAIx4YoBIhobWBsZAiJgD4P9a rMr4IaFesq/b7P/2FJMSHmezXm3F9J772VLaU6qIlvFfNxcUDTTIGT+E7OoJkrL8 c29hS6flMtXdCq9EUf3f1NtEONv0QoS1yEEXcbyFOBioJ4+59h1OszAgtkMsI2r5 t0Yt5l2R8a6mxKrm7JeMYc8ClQ2VVLcaHLm3EIata1sAexpE/kq8eEeYTRAzzD4M x/k0Is/wsk9MV1m7L5WkkezZuOYV5MW5R2BJhlAwUAAhLs4sM52dzq1AkzPvst3s useStynywUAUO3gc3/3mSu11LSfBAEhIQF9JBQNTcteXTOuLcO9L6+7HAzNSWe0= =vcKa -----END PGP SIGNATURE----- --xCiNp3em6rDbgM42qm9wxbURXNeTMC5dA--