qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [Qemu-devel][PATCH]block/truncate: qcow2’s resize stat


From: Kevin Wolf
Subject: Re: [Qemu-block] [Qemu-devel][PATCH]block/truncate: qcow2’s resize status is not showed to
Date: Wed, 15 Jul 2015 10:50:09 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 15.07.2015 um 03:57 hat 김태하 geschrieben:
> To put it briefly, when resize qcow2 image, the "file" tool detected increased
> size. However, the "ls", “stat”, and “du” utility still don't know increased
> size. The following patch enables to let userland tools - ls, du, stat - know
> and apply changed size after resizing qcow2 image created by the qemu-img 
> tool.
> Currently, can know only using “file” utility without this patch.

Even your goal is already wrong. For any image format other than raw,
the file size doesn't represent the virtual disk size. It's just the
size that the image file actually takes on the host, and that's
something entirely different.

The correct way to check the virtual disk size is 'qemu-img info'.

> ======================
> 
> Signed-off-by: Taeha Kim <address@hidden>
> 
> diff --git a/block.c b/block.c
> index 5e80336..277adf3 100644
> --- a/block.c
> +++ b/block.c
> @@ -2473,6 +2473,9 @@ int bdrv_truncate(BlockDriverState *bs, int64_t offset)
>        if (bs->blk) {
>            blk_dev_resize_cb(bs->blk);
>        }
> +       if (ret == 0) {
> +           ret = truncate(bs->filename, offset);
> +       }
>    }
>    return ret;
> }

Even if your goal were right, this wouldn't work because images don't
have to be local files.

And to be clear: Truncating the image file is not only misguided and
unnecessary, but it will actively corrupt image files, because qcow2
images can be larger than the virtual disk size (e.g. if you have taken
some snapshots). In this case you would destroy the image by throwing
away part of it.

Kevin



reply via email to

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