From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43926 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P6LdX-0000Hw-Qn for qemu-devel@nongnu.org; Thu, 14 Oct 2010 07:06:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P6LdW-0005M7-JY for qemu-devel@nongnu.org; Thu, 14 Oct 2010 07:06:15 -0400 Received: from mtagate7.uk.ibm.com ([194.196.100.167]:33178) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P6LdW-0005Lc-Bx for qemu-devel@nongnu.org; Thu, 14 Oct 2010 07:06:14 -0400 Received: from d06nrmr1806.portsmouth.uk.ibm.com (d06nrmr1806.portsmouth.uk.ibm.com [9.149.39.193]) by mtagate7.uk.ibm.com (8.13.1/8.13.1) with ESMTP id o9EB6AOF022425 for ; Thu, 14 Oct 2010 11:06:10 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o9EB6Ai62809994 for ; Thu, 14 Oct 2010 12:06:10 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o9EB6ABN030750 for ; Thu, 14 Oct 2010 12:06:10 +0100 Date: Thu, 14 Oct 2010 12:06:09 +0100 From: Stefan Hajnoczi Subject: Re: [Qemu-devel] Re: [PATCH v2 6/7] qed: Read/write support Message-ID: <20101014110609.GA4071@stefan-thinkpad.transitives.com> References: <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> <4CB5B2FD.9030205@linux.vnet.ibm.com> <4CB5B908.1020406@redhat.com> <20101013140715.GF8998@stefan-thinkpad.transitives.com> <4CB5BDD1.8050409@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CB5BDD1.8050409@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Kevin Wolf , Anthony Liguori , qemu-devel@nongnu.org, Christoph Hellwig On Wed, Oct 13, 2010 at 04:10:25PM +0200, Avi Kivity wrote: > On 10/13/2010 04:07 PM, Stefan Hajnoczi wrote: > >On Wed, Oct 13, 2010 at 03:50:00PM +0200, Avi Kivity wrote: > >> On 10/13/2010 03:24 PM, Anthony Liguori wrote: > >> >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()). > >> > >> If you make QED_F_PHYSICAL_SIZE an autoclear bit, you don't need the > >> header dirty bit. > > > >Do you mean we just need to check the physical size header field against > >the actual file size? If the two are different, then a consistency > >check is forced. > > I thought you'd only use a header size field when you don't have a > real file size. Why do you need both? I probably didn't understand correctly :). You said with QED_F_PHYSICAL_SIZE autoclear you don't need the header dirty bit. I don't see how it eliminates the need for the header dirty bit. Stefan