qemu-devel
[Top][All Lists]
Advanced

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

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


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

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



reply via email to

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