From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDsmP-0004MR-7d for qemu-devel@nongnu.org; Fri, 08 Mar 2013 03:35:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UDsmI-0000f1-Tk for qemu-devel@nongnu.org; Fri, 08 Mar 2013 03:35:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51461) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDsmI-0000eM-M3 for qemu-devel@nongnu.org; Fri, 08 Mar 2013 03:35:46 -0500 Date: Fri, 8 Mar 2013 09:35:43 +0100 From: Kevin Wolf Message-ID: <20130308083542.GA2451@dhcp-200-207.str.redhat.com> References: <20130307143044.GC27175@stefanha-thinkpad.redhat.com> <20130307152354.GE22782@localhost.localdomain> <20130307161228.GA28227@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130307161228.GA28227@stefanha-thinkpad.redhat.com> Subject: Re: [Qemu-devel] [PATCH 4/7] block: initial VHDX driver support framework - supports open and probe List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: sw@weilnetz.de, Jeff Cody , qemu-devel@nongnu.org Am 07.03.2013 um 17:12 hat Stefan Hajnoczi geschrieben: > On Thu, Mar 07, 2013 at 10:23:54AM -0500, Jeff Cody wrote: > > On Thu, Mar 07, 2013 at 03:30:44PM +0100, Stefan Hajnoczi wrote: > > > On Wed, Mar 06, 2013 at 09:48:11AM -0500, Jeff Cody wrote: > > > > + ret = bdrv_pread(bs->file, s->bat_offset, s->bat, s->bat_rt.length); > > > > + > > > > + for (i = 0; i < s->bat_entries; i++) { > > > > + le64_to_cpus(&s->bat[i]); > > > > + } > > > > > > How does BAT size scale when the image size is increased? QCOW2 and QED > > > use caches for metadata that would be too large or wasteful to keep in > > > memory. > > > > The BAT size is dependent on the virtual disk size, and the block > > size. The block size is allowed to range from 1MB - 256MB. There is > > one BAT entry per block. > > > > In practice, the large block size keeps the BAT entry table reasonable > > (for a 127GB file, the block size created by Hyper-V is 32MB, so the > > table is pretty small - 32KB). > > > > However, I don't see anything in the spec that forces the block size > > to be larger, for a large virtual disk size. So for the max size of > > 64TB, and the smallest block size of 1MB, keeping the BAT in memory > > would indeed be excessive. > > > > I'll re-read the spec, and see if there is anything that ties the > > block size and virtual size together. If not, I'll have to add > > caching. > > BTW the qcow2 cache code can be reused. The add-cow series has patches to make it work outside of qcow2. I'm not sure if there was something wrong with this part of the series, but at least it could be a starting point. Kevin