From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60915) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPiTp-0002iq-Vf for qemu-devel@nongnu.org; Tue, 19 Jul 2016 23:47:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPiTn-0007Wq-VU for qemu-devel@nongnu.org; Tue, 19 Jul 2016 23:47:29 -0400 References: <1468901281-22858-1-git-send-email-eblake@redhat.com> <1468901281-22858-14-git-send-email-eblake@redhat.com> <20160719062131.GG18103@ad.usersys.redhat.com> <578E4708.5080308@redhat.com> <20160720033402.GA7641@ad.usersys.redhat.com> From: Eric Blake Message-ID: <578EF446.70202@redhat.com> Date: Tue, 19 Jul 2016 21:47:18 -0600 MIME-Version: 1.0 In-Reply-To: <20160720033402.GA7641@ad.usersys.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gTLLMEmoSFEaeh32Jvt1FG8FoJaDGctFA" Subject: Re: [Qemu-devel] [PATCH v5 13/14] nbd: Implement NBD_CMD_WRITE_ZEROES on server List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng , Paolo Bonzini Cc: Kevin Wolf , "nbd-general@lists.sourceforge.net" , qemu-devel@nongnu.org, qemu-block@nongnu.org, Max Reitz This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gTLLMEmoSFEaeh32Jvt1FG8FoJaDGctFA From: Eric Blake To: Fam Zheng , Paolo Bonzini Cc: Kevin Wolf , "nbd-general@lists.sourceforge.net" , qemu-devel@nongnu.org, qemu-block@nongnu.org, Max Reitz Message-ID: <578EF446.70202@redhat.com> Subject: Re: [Qemu-devel] [PATCH v5 13/14] nbd: Implement NBD_CMD_WRITE_ZEROES on server References: <1468901281-22858-1-git-send-email-eblake@redhat.com> <1468901281-22858-14-git-send-email-eblake@redhat.com> <20160719062131.GG18103@ad.usersys.redhat.com> <578E4708.5080308@redhat.com> <20160720033402.GA7641@ad.usersys.redhat.com> In-Reply-To: <20160720033402.GA7641@ad.usersys.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/19/2016 09:34 PM, Fam Zheng wrote: > On Tue, 07/19 17:45, Paolo Bonzini wrote: >> >> >> On 19/07/2016 17:28, Eric Blake wrote: >>>> If I'm reading the NBD proto.md correctly, this is not enough if >>>> NBD_CMD_FLAG_NO_HOLE is specified. We probably need to use a zeroed = buffer with >>>> blk_pwrite, or pass a new flag (BDRV_RED_NO_HOLE) to blk_pwrite_zero= es to >>>> enforce the bdrv_driver_pwritev() branch in bdrv_co_do_pwrite_zeroes= (). >> >> I agree with Eric's interpretation. It's a bit weird to have the >> direction inverted, but I'm not sure I see the ambiguity. Can you exp= lain? >=20 > Write zeroes _means_ "punch hole" on a raw file. >=20 > In block/raw-posix.c:handle_aiocb_write_zeroes(): >> #ifdef CONFIG_FALLOCATE_PUNCH_HOLE >> if (s->has_discard && s->has_fallocate) { >> int ret =3D do_fallocate(s->fd, >> FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_S= IZE, >> aiocb->aio_offset, aiocb->aio_nbytes); >> if (ret =3D=3D 0) { >> ret =3D do_fallocate(s->fd, 0, aiocb->aio_offset, aiocb->a= io_nbytes); That is just implementation: punch a hole, BUT THEN reallocate it back, so that in the end, the file is still not sparse in that region. Or am I reading it wrong? But the implementation under the hood is not visible to the guest - as long as the end result is that a guest requesting NO_HOLE ends up with a non-sparse file, and the data reads back as all 0, the client doesn't care whether the zeros were written byte-by-byte or sped up by punching a hole then reallocating. >=20 > And unmap is translated to "punch hole", too. >=20 > In block/raw-posix.c:handle_aiocb_discard(): >> #ifdef CONFIG_FALLOCATE_PUNCH_HOLE >> ret =3D do_fallocate(s->fd, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_K= EEP_SIZE, >> aiocb->aio_offset, aiocb->aio_nbytes); >> #endif No, this call is different - it punches a hole, then stops. There is no followup do_fallocate(,0,,) to reallocate, so the file remains sparse. >=20 > So I agree that NBD_CMD_FLAG_NO_HOLE is a poorly named flag, because th= ere is > always going to be a hole event if it's set. If we are punching holes even when BDRV_REQ_MAY_UNMAP is not set, that seems like we have a bug in qemu (unless we are immediately then reallocating so that there is no resulting hole). --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --gTLLMEmoSFEaeh32Jvt1FG8FoJaDGctFA 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/ iQEcBAEBCAAGBQJXjvRGAAoJEKeha0olJ0NqUTMH/1SZqV3najzu0CJa7cL0pS8X mG3+JmyaDG+UaSFv8JTmbAtOmA4kj/5adXAd5+9vs9yODjNv//nU9rwvlED0rSWB F3Sp6hOAhszTRE4GVN6fYLWB10d5sP8N3EneiGnsISjFwA2CUhvSTVNE5vgnC28s AMrRgevztBiXGqposT+dOuQyf0+sNdGVCArfngBurpCEtEtEXlNIt7COEYIe2372 MuXqBsttTM2aNb64SmNgmrwYHxSLdmnb59BG+ewxlgOiXtQyHYUIrMxg5trJ2t0i 4b1GsEBe8FM3PfFY7m2Pi4xu5bWQknFW0yEfDN8nEA41gcSIAzfLUNBfmkGEElc= =43Sk -----END PGP SIGNATURE----- --gTLLMEmoSFEaeh32Jvt1FG8FoJaDGctFA--