From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52788) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPX07-0004oe-IM for qemu-devel@nongnu.org; Tue, 19 Jul 2016 11:32:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPX02-0006RW-35 for qemu-devel@nongnu.org; Tue, 19 Jul 2016 11:32:02 -0400 References: <1468901281-22858-1-git-send-email-eblake@redhat.com> <1468901281-22858-15-git-send-email-eblake@redhat.com> <20160719062420.GH18103@ad.usersys.redhat.com> From: Eric Blake Message-ID: <578E47E8.1060205@redhat.com> Date: Tue, 19 Jul 2016 09:31:52 -0600 MIME-Version: 1.0 In-Reply-To: <20160719062420.GH18103@ad.usersys.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fVJEHtG4ORVvsEj9AFu8QBbTWfAwB2haF" Subject: Re: [Qemu-devel] [PATCH v5 14/14] nbd: Implement NBD_CMD_WRITE_ZEROES on client List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: qemu-devel@nongnu.org, Kevin Wolf , pbonzini@redhat.com, qemu-block@nongnu.org, Max Reitz This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fVJEHtG4ORVvsEj9AFu8QBbTWfAwB2haF From: Eric Blake To: Fam Zheng Cc: qemu-devel@nongnu.org, Kevin Wolf , pbonzini@redhat.com, qemu-block@nongnu.org, Max Reitz Message-ID: <578E47E8.1060205@redhat.com> Subject: Re: [Qemu-devel] [PATCH v5 14/14] nbd: Implement NBD_CMD_WRITE_ZEROES on client References: <1468901281-22858-1-git-send-email-eblake@redhat.com> <1468901281-22858-15-git-send-email-eblake@redhat.com> <20160719062420.GH18103@ad.usersys.redhat.com> In-Reply-To: <20160719062420.GH18103@ad.usersys.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/19/2016 12:24 AM, Fam Zheng wrote: > On Mon, 07/18 22:08, Eric Blake wrote: >> Upstream NBD protocol recently added the ability to efficiently >> write zeroes without having to send the zeroes over the wire, >> along with a flag to control whether the client wants a hole. >> >> +int nbd_client_co_pwrite_zeroes(BlockDriverState *bs, int64_t offset,= >> + int count, BdrvRequestFlags flags) >> +{ >> + ssize_t ret; >> + NbdClientSession *client =3D nbd_get_client_session(bs); >> + struct nbd_request request =3D { >> + .type =3D NBD_CMD_WRITE_ZEROES, >> + .from =3D offset, >> + .len =3D count, >> + }; >> + struct nbd_reply reply; >> + >> + if (!(client->nbdflags & NBD_FLAG_SEND_WRITE_ZEROES)) { >> + return -ENOTSUP; >> + } >> + >> + if (flags & BDRV_REQ_FUA) { >> + assert(client->nbdflags & NBD_FLAG_SEND_FUA); >> + request.flags |=3D NBD_CMD_FLAG_FUA; >> + } >> + if (!(flags & BDRV_REQ_MAY_UNMAP)) { >=20 > Correct me if I'm wrong, I don't think we care about BDRV_REQ_MAY_UNMAP= here, > the NBD protocol can never issue an unmap request. In other words I thi= nk > NO_HOLE and MAY_UNMAP are two different things. No. The server is (and should be) allowed to manage storage as efficiently as it wants, and should only be required to fully allocate storage if the client has requested that. The NBD protocol CAN issue an unmap request (NBD_CMD_TRIM), but we also document in the NBD protocol that the server SHOULD be able to unmap instead of writing zeroes so long as the result still reads as zeroes. So we WANT to issue MAY_UNMAP as an optimization in all cases except where the client specifically asked for full allocation. NO_HOLE and MAY_UNMAP are (supposed to be) the same thing, except for being negated in sense based on what the default value of 0 represents. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --fVJEHtG4ORVvsEj9AFu8QBbTWfAwB2haF 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/ iQEcBAEBCAAGBQJXjkfoAAoJEKeha0olJ0NqzPMH/ijWmB1ZuNF2EV3i0Urv4mjj o+j50mTMMmNXVbUB7Dl/9q37lSwadMTBeBw4C0Gt6tOZXDvr+jiSOScNHVCKY4M1 eiQ3pECGEAichAGUAJVjDPlMgEhjli+TAi2wNFtbxb3tewQdB2J5D0Y5ZQ+mVWHC K7GXgGvvz+xhoVV7iMkNgLBUh56J3Cs+3qxwqUAO3pq2vV7pWuxzB7xXnDMZCGBW TYNz5uCPeEIDgI9V0hLv6WQ4Ji82BhrwgY/QWDI2Lg8vZctwRVrsgV3EFjwG0XkL GOb1XDxxUd5Z8ACzS2h0GFNo1pRcYVeKqV/7mNdkGZYVLrc74hwxy549bjCo0sU= =e/vE -----END PGP SIGNATURE----- --fVJEHtG4ORVvsEj9AFu8QBbTWfAwB2haF--