From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57607 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P61Jb-00081n-Ec for qemu-devel@nongnu.org; Wed, 13 Oct 2010 09:24:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P61Ja-0002x5-GX for qemu-devel@nongnu.org; Wed, 13 Oct 2010 09:24:19 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]:55742) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P61Ja-0002wu-B3 for qemu-devel@nongnu.org; Wed, 13 Oct 2010 09:24:18 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o9DDJ0Ft017061 for ; Wed, 13 Oct 2010 07:19:00 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id o9DDOHvT259044 for ; Wed, 13 Oct 2010 07:24:17 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o9DDOFVT019645 for ; Wed, 13 Oct 2010 07:24:15 -0600 Message-ID: <4CB5B2FD.9030205@linux.vnet.ibm.com> Date: Wed, 13 Oct 2010 08:24:13 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH v2 6/7] qed: Read/write support References: <1286552914-27014-1-git-send-email-stefanha@linux.vnet.ibm.com> <1286552914-27014-7-git-send-email-stefanha@linux.vnet.ibm.com> <4CB479D2.7030901@redhat.com> <4CB47D38.3060602@linux.vnet.ibm.com> <4CB48144.9030607@redhat.com> <20101012155953.GA13872@stefan-thinkpad.transitives.com> <4CB489D1.3050204@linux.vnet.ibm.com> <20101013121328.GB8998@stefan-thinkpad.transitives.com> <4CB5AF0D.9000800@redhat.com> In-Reply-To: <4CB5AF0D.9000800@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org, Christoph Hellwig , Stefan Hajnoczi , Avi Kivity On 10/13/2010 08:07 AM, Kevin Wolf wrote: > Am 13.10.2010 14:13, schrieb Stefan Hajnoczi: > >> We can avoid it when a backing image is not used. Your idea to check >> for zeroes in the backing image is neat too, it may well reduce the >> common case even for backing images. >> > The additional requirement is that we're extending the file and not > reusing an old cluster. (And bdrv_has_zero_init() == true, but QED > doesn't work on host_devices anyway) > Yes, that's a good point. BTW, I think we've decided that making it work on host_devices is not that bad. We can add an additional feature called QED_F_PHYSICAL_SIZE. This feature will add another field to the header that contains an offset immediately following the last cluster allocation. During a metadata scan, we can accurately recreate this field so we only need to update this field whenever we clear the header dirty bit (which means during an fsync()). That means we can maintain the physical size without introducing additional fsync()s in the allocation path. Since we're already writing out the header anyway, the write operation is basically free too. Regards, Anthony Liguori > Kevin >