From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36825) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vtzbm-0008HR-0K for qemu-devel@nongnu.org; Fri, 20 Dec 2013 07:55:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vtzbg-00064s-W9 for qemu-devel@nongnu.org; Fri, 20 Dec 2013 07:55:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56670) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vtzbg-00064m-O8 for qemu-devel@nongnu.org; Fri, 20 Dec 2013 07:55:08 -0500 Message-ID: <52B43E0A.3020401@redhat.com> Date: Fri, 20 Dec 2013 05:54:34 -0700 From: Eric Blake MIME-Version: 1.0 References: <20131220103021.GH27021@stefanha-thinkpad.redhat.com> In-Reply-To: <20131220103021.GH27021@stefanha-thinkpad.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bGtIkjq9G4Vm3JmxmSPxama7WpQSBVLkv" Subject: Re: [Qemu-devel] [RFC PATCH v3 0/6] qemu-img: add preallocation=full List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi , Hu Tao Cc: Kevin Wolf , Peter Lieven , Fam Zheng , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bGtIkjq9G4Vm3JmxmSPxama7WpQSBVLkv Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/20/2013 03:30 AM, Stefan Hajnoczi wrote: > On Thu, Dec 19, 2013 at 10:27:35AM +0800, Hu Tao wrote: >> This series implements full image preallocation to create a non-sparse= image >> file at creation time, both for raw and qcow2 format. The purpose is t= o avoid >> performance deterioration of the guest cause by sparse image. >=20 > I'm not sure the new bdrv_preallocate() interface is necessary. Can > qcow2_create() simply pass a preallocate=3Dfull option to > bdrv_create_file()? >=20 > It's simpler if we avoid bdrv_preallocate(), just keep it a > .bdrv_create() option. That way we also avoid the question of how > exactly preallocate functions on an image file that already has blocks > allocated. >=20 > So what I imagine is: > 1. Add preallocation=3Dfull support to raw-posix.c > 2. Add preallocation=3Dfull support to qcow2.c, calculate image file si= ze > including metadata for bdrv_create_file(). >=20 > CCing Eric Blake so libvirt can consider how full preallocation > interacts with their safezero() preallocation. If QEMU handles > preallocation can we skip safezero()? Is there a concern about full > preallocation in QEMU taking a long time without progress report? If libvirt can detect that qemu is new enough to do preallocation, then libvirt can skip its own preallocation. Which means you need to make sure that QMP can probe the existence of this new feature (probably already possible via query-command-line-options, but see also my reply to 1/6 about starting to put this in QAPI). The fact that preallocation is sometimes long running is definitely worth considering; but it raises the more generic issue of how to turn any long running blocking command into an asynchronous job that gets started, then has both polling and event-notification progress until completion, as well as the option of an early abort if it is taking too long. And there's my long-standing gripe that qemu-img doesn't support -p progress meters for enough of its already-existing long-running commands, which makes it harder for libvirt to provide wrappers around qemu-img operations when manipulating images not associated with a running VM. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --bGtIkjq9G4Vm3JmxmSPxama7WpQSBVLkv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJStD4KAAoJEKeha0olJ0Nq4u8H/2InF+b8u8j1CIYgv/cb1jpC QA72R8u+zlm9z/Pnw7pqgMo99AcOIi43MfGP6gqvJKvBtS2aYx6jgde4B3V188Wy JSIc+OYEzUSlnwb5rspw1jeyPGHI8H6IcSVACHGrUxwxaABlx+iDFUaUX4WuR3x7 GVLDKJgW0WUgjt7LNWRXVJCBIaYGxVkkmBBM93Z/eUtUHCWsY1bNxso2p1xPw58D zlljS/kPTI1kKmDesL+0FbgETaK3g6ZlDTIicPrIvypqP6PsGEnZHx35Uyknw83b aM8KUQoethBfZ2iCh2cr0ul3Ev9ESm+RnfL/KJ+KE845X8IhAsBWLElOGMS8axM= =WpKW -----END PGP SIGNATURE----- --bGtIkjq9G4Vm3JmxmSPxama7WpQSBVLkv--