From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43517) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RE0Dv-0000yB-7F for qemu-devel@nongnu.org; Wed, 12 Oct 2011 10:56:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RE0Dl-0005qN-M4 for qemu-devel@nongnu.org; Wed, 12 Oct 2011 10:55:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63992) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RE0Dl-0005qF-7o for qemu-devel@nongnu.org; Wed, 12 Oct 2011 10:55:49 -0400 Message-ID: <4E95AB28.5090106@redhat.com> Date: Wed, 12 Oct 2011 16:58:48 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1309187514-26562-1-git-send-email-kwolf@redhat.com> <4E9596CF.9090305@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v2] Specification for qcow2 version 3 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: ctang@us.ibm.com, avi@redhat.com, hch@lst.de, Frediano Ziglio , qemu-devel@nongnu.org Am 12.10.2011 16:37, schrieb Stefan Hajnoczi: > On Wed, Oct 12, 2011 at 2:31 PM, Kevin Wolf wrote: >> Am 12.10.2011 14:51, schrieb Stefan Hajnoczi: >>>> Also a bit in l2 offset to say "there is no l2 table" cause all >>>> clusters in l2 are contiguous so we avoid entirely l2. Obviously this >>>> require an optimization step to detect or create such condition. >>> >>> There are several reserved L1 entry bits which could be used to mark >>> this mode. This mode severely restricts qcow2 features though: how >>> would snapshots and COW work? Perhaps by breaking the huge cluster >>> back into an L2 table with individual clusters? Backing files also >>> cannot be used - unless we extend the sub-clusters approach and also >>> keep a large bitmap with allocated/unallocated/zero information. >>> >>> A mode like this could be used for best performance on local storage, >>> where efficiently image transport (e.g. scp or http) is not required. >>> Actually I think this is reasonable, we could use qemu-img convert to >>> produce a compact qcow2 for export and use the L2-less qcow2 for >>> running the actual VM. >>> >>> Kevin: what do you think about fleshing out this mode instead of sub-clusters? >> >> I'm hesitant to something like this as it adds quite some complexity and >> I'm not sure if there are practical use cases for it at all. >> >> If you take the current cluster sizes, an L2 table contains 512 MB of >> data, so you would lose any sparseness. You would probably already get >> full allocation just by creating a file system on the image. >> >> But even if you do have a use case where sparseness doesn't matter, the >> effect is very much the same as allowing a 512 MB cluster size and not >> changing any of the qcow2 internals. > > I guess I'm thinking of the 512 MB cluster size situation, because > we'd definitely want a cow bitmap in order to keep backing files and > sparseness. > >> (What would the use case be? Backing files or snapshots with a COW >> granularity of 512 MB isn't going to fly. That leaves only something >> like encryption.) > > COW granularity needs to stay at 64-256 kb since those are reasonable > request sizes for COW. But how do you do that without L2 tables? What you're describing (different sizes for allocation and COW) is exactly what subclusters are doing. I can't see how switching to 512 MB clusters and a single-level table can make that work. Kevin