From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60314) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1an4zR-0006PQ-4L for qemu-devel@nongnu.org; Mon, 04 Apr 2016 09:56:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1an4zL-0002Ua-JX for qemu-devel@nongnu.org; Mon, 04 Apr 2016 09:56:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52032) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1an4zL-0002TX-BG for qemu-devel@nongnu.org; Mon, 04 Apr 2016 09:56:19 -0400 References: <1459546186-17002-1-git-send-email-eblake@redhat.com> From: Eric Blake Message-ID: <57027280.1020800@redhat.com> Date: Mon, 4 Apr 2016 07:56:16 -0600 MIME-Version: 1.0 In-Reply-To: <1459546186-17002-1-git-send-email-eblake@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iHbkmbLfkgXD8rTbtkv9cqaKvPkRsDcvJ" Subject: Re: [Qemu-devel] [Nbd] [PATCH] doc: Flip bit sense for allowing trim during WRITE_ZEROES List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: nbd-general@lists.sourceforge.net Cc: den@openvz.org, qemu-devel@nongnu.org, pborzenkov@virtuozzo.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iHbkmbLfkgXD8rTbtkv9cqaKvPkRsDcvJ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/01/2016 03:29 PM, Eric Blake wrote: > Rather than requiring allocation by default and allowing trims > only on request during WRITE_ZEROES, it seems like a better > default is to allow server optimizations by default and require > full allocation by specific request. Since WRITE_ZEROES is > experimental and has not yet been implemented, we can flip the > sense of the command flag so that the default flags of all 0s > is the most efficient, and flags (whether _FUA or _NO_HOLE) are > added to make the operation have tighter constraints but > possibly slower execution. >=20 > The name NO_HOLE is also slightly nicer at expressing the fact > that there is no dependency on whether NBD_CMD_TRIM is supported. >=20 > - If the flag `NBD_CMD_FLAG_MAY_TRIM` was set by the client in the c= ommand > - flags field, the server MAY use trimming to zero out the area, but= it > - MUST ensure that the data reads back as zero. > + 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 > + that the data reads back as zero. However, the client MAY set the= > + command flag `NBD_CMD_FLAG_NO_HOLE` to inform the server that the > + area MUST be fully provisioned, ensuring that future writes to the= > + same area will not cause fragmentation or cause failure due to > + insufficient space. Question - qemu already has the notion of an nbd server that can be configured to explicitly check for large repetitions of zero during NBD_CMD_WRITE, and create holes in the corresponding file as a result (basically because qemu is compensating for NBD_CMD_WRITE_ZEROES not being part of the protocol yet, so that the destination file can still be sparse even though lots of zeroes were sent over the wire). Should we also allow servers to accept NBD_CMD_FLAG_NO_HOLE during NBD_CMD_WRITE as an explicit request to NOT perform the magic of searching for large runs of zeroes, but to just write everything as written? For older qemu clients that are not aware of the new WRITE_ZEROES command, the client will also not use the NO_HOLE flag for normal writes, and everything is at the mercy of the server recognizing zeroes. But for newer qemu clients, it can be usefully assumed that the client will always prefer WRITE_ZEROES (without flags) when it is okay to punch a hole, and therefore that the new client will also send the NO_HOLE flag to normal WRITE to inform the server that it doesn't need to waste time searching for large runs of zeroes. If this sounds reasonable, I'll go ahead and propose a patch. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --iHbkmbLfkgXD8rTbtkv9cqaKvPkRsDcvJ 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/ iQEcBAEBCAAGBQJXAnKAAAoJEKeha0olJ0NqBroH/095pa8LL59g8MPU2d9taG90 Zj9wZLvnPFUknsi8a2shKRDHVXs8sBbuaKcdzo5tpWYSby+xbgg2sCpuoz9Pumma o+3V/U0RY8YFfg7wTaxLxl8+bIKWE4vE6DE4Qj0DWw2/VXQeBfBYnRCtiZPFjTop lHU4S9th8kQfMwA1zhOzp54T5NSl1wJqvCI5B3Ie0GfLhzY4gZK9gRwnY6awRmdl SArj0d0PLlzqeMCf0A8Lg3PllnlUfm/eIBLbuMMjAiNcLODF4xw+5q1lbXPCmkVn PfC+jN+tCI4DcqkN03uGp8xZQqF2eejpGXS/4WVyyYDGjGj75j6/cBkoVXihFW8= =w1bI -----END PGP SIGNATURE----- --iHbkmbLfkgXD8rTbtkv9cqaKvPkRsDcvJ--