From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33332) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtxLm-0006W4-1M for qemu-devel@nongnu.org; Fri, 20 Dec 2013 05:30:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VtxLd-0005HK-JZ for qemu-devel@nongnu.org; Fri, 20 Dec 2013 05:30:33 -0500 Received: from mail-wi0-x232.google.com ([2a00:1450:400c:c05::232]:62798) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtxLd-0005HG-9A for qemu-devel@nongnu.org; Fri, 20 Dec 2013 05:30:25 -0500 Received: by mail-wi0-f178.google.com with SMTP id bz8so3463863wib.11 for ; Fri, 20 Dec 2013 02:30:24 -0800 (PST) Date: Fri, 20 Dec 2013 11:30:21 +0100 From: Stefan Hajnoczi Message-ID: <20131220103021.GH27021@stefanha-thinkpad.redhat.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Hu Tao Cc: Kevin Wolf , Peter Lieven , Fam Zheng , qemu-devel@nongnu.org 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 to avoid > performance deterioration of the guest cause by sparse image. I'm not sure the new bdrv_preallocate() interface is necessary. Can qcow2_create() simply pass a preallocate=full option to bdrv_create_file()? 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. So what I imagine is: 1. Add preallocation=full support to raw-posix.c 2. Add preallocation=full support to qcow2.c, calculate image file size including metadata for bdrv_create_file(). 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? Stefan