From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39338) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dpDU6-0000na-JY for qemu-devel@nongnu.org; Tue, 05 Sep 2017 09:01:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dpDU1-0008Cj-Vd for qemu-devel@nongnu.org; Tue, 05 Sep 2017 09:01:42 -0400 Date: Tue, 5 Sep 2017 15:01:07 +0200 From: Kevin Wolf Message-ID: <20170905130107.GJ4633@localhost.localdomain> References: <0988b4ef-56e2-5ce9-ed25-40a742eadbd4@redhat.com> <20170828025706.GA18194@lemon.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170828025706.GA18194@lemon.lan> Subject: Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: Max Reitz , John Snow , Vladimir Sementsov-Ogievskiy , Qemu-block , qemu-devel , Stefan Hajnoczi , Manos Pitsidianakis Am 28.08.2017 um 04:57 hat Fam Zheng geschrieben: > On Fri, 08/25 15:44, Max Reitz wrote: > > Well, OK. The main argument against supporting anything but qcow2 is > > "if you want features, use qcow2; and we are working on making qcow2 as > > fast as possible." I think that's a very good argument still. At some > > point I (and probably others, too) had the idea of making qcow2 files in > > raw layout: > > Yes! I think this idea makes a whole lot of sense, too. Metadata tables can be > generated so old implementation can still use it. Maybe a nice way to attack this would be "huge pages", i.e. have a L1 entry flag that tells "this points directly to a huge cluster instead of an L2 table". Gives us 512 MB clusters with a 64k cluster size, or a maximum of 512 GB clusters with a 2 MB cluster size. Huge clusters would only be used by qemu-img create if the respective option is given, and only with preallocation. Kevin