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