From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53513) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dpF1a-0007lI-SX for qemu-devel@nongnu.org; Tue, 05 Sep 2017 10:40:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dpF1R-0005Uw-9p for qemu-devel@nongnu.org; Tue, 05 Sep 2017 10:40:22 -0400 Date: Tue, 5 Sep 2017 16:39:49 +0200 From: Kevin Wolf Message-ID: <20170905143949.GM4633@localhost.localdomain> References: <0988b4ef-56e2-5ce9-ed25-40a742eadbd4@redhat.com> <20170828025706.GA18194@lemon.lan> <20170905130107.GJ4633@localhost.localdomain> <20170905131858.GW22515@lemon.lan> <20170905132756.GL4633@localhost.localdomain> <20170905133957.GX22515@lemon.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170905133957.GX22515@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: Vladimir Sementsov-Ogievskiy , Qemu-block , Manos Pitsidianakis , qemu-devel , Max Reitz , Stefan Hajnoczi , John Snow Am 05.09.2017 um 15:39 hat Fam Zheng geschrieben: > On Tue, 09/05 15:27, Kevin Wolf wrote: > > Am 05.09.2017 um 15:18 hat Fam Zheng geschrieben: > > > On Tue, 09/05 15:01, Kevin Wolf wrote: > > > > 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. > > > > > > Then this image is not usable on old QEMUs, right? So this is going to be an > > > incompatible_feature, whereas with the linear mapping L1/L2 tables approach, it > > > can be an autoclear_feature. > > > > Ah yes, that's true. Maybe that's important enough that just a single > > global flag is better, even if it's less flexible. > > > > Of course, this approach also means that we still need to write all of > > the L2 tables and use disk space for them, even though newer versions > > will never look at them. > > To speculate^Wmitigate, "qemu-img create" is free to pick a larger cluster size > when this feature is used? Seems reasonable, though the 2 MB limit for the cluster size still applies. Kevin