qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 5/7] block/vpc: Fix size calculation


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 5/7] block/vpc: Fix size calculation
Date: Tue, 05 Feb 2013 11:54:57 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0

Am 01.02.2013 22:51, schrieb Stefan Weil:
> The size calculated from the CHS values is not the real image (disk) size,
> but usually a smaller value (this is caused by rounding effects).
> 
> Only older operating systems use CHS. Such guests won't be able to use
> the whole disk.
> 
> This patch fixes https://bugs.launchpad.net/qemu/+bug/1105670/.
> 
> Signed-off-by: Stefan Weil <address@hidden>
> ---
>  block/vpc.c |    9 ++++-----
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/block/vpc.c b/block/vpc.c
> index fff103b..799b1c9 100644
> --- a/block/vpc.c
> +++ b/block/vpc.c
> @@ -198,11 +198,10 @@ static int vpc_open(BlockDriverState *bs, int flags)
>      /* Write 'checksum' back to footer, or else will leave it with zero. */
>      footer->checksum = be32_to_cpu(checksum);
>  
> -    // The visible size of a image in Virtual PC depends on the geometry
> -    // rather than on the size stored in the footer (the size in the footer
> -    // is too large usually)
> -    bs->total_sectors = (int64_t)
> -        be16_to_cpu(footer->cyls) * footer->heads * footer->secs_per_cyl;
> +    /* The visible size of an image in Virtual PC may depend on the geometry
> +     * rather than on the size stored in the footer (the size in the footer
> +     * is usually larger). Nevertheless we must use the real size here. */
> +    bs->total_sectors = be64_to_cpu(footer->size) / 512;
>  
>      /* Allow a maximum disk size of approximately 2 TB */
>      if (bs->total_sectors >= 65535LL * 255 * 255) {

Now VMs created with qemu can't be run in Virtual PC any more because
they use more space than is really visible on VPC.

The bug report doesn't say anything about practical consequences of the
unexpected behaviour, so I'd tend to claim that just the expectation was
wrong. Having to deal with two differing sizes is ugly, but we had the
discussion before and using the geometry was considered the least bad
way, because it gives you the same disk size within the VM as on Virtual PC.

If you want to change it, you need to provide a real use case that breaks.

Kevin



reply via email to

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