Am 18.10.2010 17:53, schrieb Stefan Hajnoczi: > The L1 table grow operation includes a size calculation that bumps up > the new L1 table size in order to anticipate the size needs of vmstate > data. This helps reduce the number of times that the L1 table has to be > grown when vmstate data is appended. > > This size overhead is not necessary during image creation, > bdrv_truncate(), or snapshot goto operations. In fact, existing > qemu-iotests that exercise table growth are no longer able to trigger it > because image creation preallocates an L1 table that is too large after > changes to qcow_create2(). > > This patch keeps the size calculation but also adds exact growth for > callers that do not want to inflate the L1 table size unnecessarily. > > Signed-off-by: Stefan Hajnoczi <stefa...@linux.vnet.ibm.com> > --- > block/qcow2-cluster.c | 25 ++++++++++++++++--------- > block/qcow2-snapshot.c | 2 +- > block/qcow2.c | 2 +- > block/qcow2.h | 2 +- > 4 files changed, 19 insertions(+), 12 deletions(-) > > Hi Kevin, > This patch fixes the qcow_create2() issue seen in qemu-iotests 026 with your > kevin.git/block branch. The issue was that the L1 table size of new images is > inflated by qcow2_grow_l1_table(). This caused the differences in the test, > e.g. L1 table grow tests no longer worked because they couldn't force the > table > to grow (it was already more than large enough). > > If we use exact L1 growth in bdrv_truncate() then less image space is wasted > and the test passes again without changes to 026.out. > > I think this patch is the way to go, not just to satisfy the test, but also > because we don't need to overallocate L1 tables to start with.
Good that you took a look at it, I hadn't even thought of changing the qcow2 code. I agree that this makes sense even independent of qemu-iotests. The patch looks good to me, too. Kevin
