qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] Persistent bitmaps for non-qcow2 formats


From: Kevin Wolf
Subject: Re: [Qemu-block] [Qemu-devel] Persistent bitmaps for non-qcow2 formats
Date: Tue, 5 Sep 2017 15:27:56 +0200
User-agent: Mutt/1.8.3 (2017-05-23)

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.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]