From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43445) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWSnd-0003W9-IY for qemu-devel@nongnu.org; Thu, 18 Feb 2016 12:55:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWSna-0008AY-BU for qemu-devel@nongnu.org; Thu, 18 Feb 2016 12:55:33 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34631) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWSna-00089f-3H for qemu-devel@nongnu.org; Thu, 18 Feb 2016 12:55:30 -0500 References: <1455732653-3106-1-git-send-email-den@openvz.org> <56C4DF07.9020806@redhat.com> <20160218091857.GA12337@rkaganb.sw.ru> <56C5F2E3.1090102@redhat.com> <56C5FDF4.4060101@openvz.org> From: Eric Blake Message-ID: <56C60590.8010501@redhat.com> Date: Thu, 18 Feb 2016 10:55:28 -0700 MIME-Version: 1.0 In-Reply-To: <56C5FDF4.4060101@openvz.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Vr4JACgwNK8VNF8orFLtf4TV06Gu95f4G" Subject: Re: [Qemu-devel] SUMMARY: Re: [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" , Roman Kagan , nbd-general@lists.sourceforge.net, qemu-devel@nongnu.org, Stefan Hajnoczi , "Daniel P. Berrange" , Vladimir Sementsov-Ogievskiy , Fam Zheng This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Vr4JACgwNK8VNF8orFLtf4TV06Gu95f4G Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/18/2016 10:23 AM, Denis V. Lunev wrote: >=20 > Here is a short summary of features which seems necessary from QEMU > point of > view: > - ability to avoid sending zeroes during write operation. The proposal > comes in > the thread-starter letter > - ability to request block status (allocate/not allocated) from server.= > This seems > interesting to preserve "sparseness" of the transferring data > - ability to skip zeroes during read operation, i.e. something like > READ2 command > which will return vector of chunks as a reply >=20 > All 3 features seem usable for generic NBD use-cases and not only for Q= EMU. All three features must be negotiated as part of connection handshake. And we want to ensure sane fallbacks: Client - if the server does not support the features, we fall back to writing explicit zeroes (and give up on sparseness), and to assuming the entire image is non-sparse (can't query or read sparseness). Server - if client requests write 0, optimize where underlying storage allows it, but we can always fall back to explicitly writing 0s and merely treating the protocol as a compression of what is sent over the wire. If client requests block status, but underlying storage doesn't provide it, we can always fall back to claiming the entire image is allocated. If client requests RAED2 but underlying storage has no way to detect holes, we can always fall back to sending a single vector covering the entire read request (no compression). >=20 > If there are no objections I'll sum this up and come with a > specification draft. Good luck! I'm sure you'll get good reviews. >=20 > Den >=20 > P.S. I have added here all parties which have participated in > conversation in > different threads on QEMU side. >=20 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --Vr4JACgwNK8VNF8orFLtf4TV06Gu95f4G 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/ iQEcBAEBCAAGBQJWxgWQAAoJEKeha0olJ0Nqb9cIAJlACpoNgXWFPbhbESnR481v Qg5lLvG9io2Ss+J9Og4usOVu/PFdZ6qtBiM8/Yirx18/Gx/SedObhdQJ60ilnPab t/qfNRCPUGtnKn49gmyFmSd0PNSepl8UqZmodHxhiiGtyiPPTNYmKQE0/8LC50gC OLBZ0tUcumKUkAo1+D4uDf7iT755Q5Y67ZqgBs84lQObKF3yAfUlJvOWqSPab3HV zq2m9ElBxmYcNZZoZKdbYP8Pn0O+0yDZPyxfZUlvLElTvIgbzzkX+ZiMda8W/mmX WXWKpHBtLJ6p+zB78OBUUri3q7kfuKbHegpIRKFmNuFXtUbIpIyo5fEN/pLrgFQ= =UcJv -----END PGP SIGNATURE----- --Vr4JACgwNK8VNF8orFLtf4TV06Gu95f4G--