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

[Fam Zheng]

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?

Fam