| Message ID | 1425379316-19639-3-git-send-email-pl@kamp.de |
|---|---|
| State | New |
| Headers | show |
On 2015-03-03 at 05:41, Peter Lieven wrote: > From: Kevin Wolf <kwolf@redhat.com> > > The CHS calculation as done per the VHD spec imposes a maximum image > size of ~127 GB. Real VHD images exist that are larger than that. > > Apparently there are two separate non-standard ways to achieve this: > You could use more heads than the spec does - this is the option that > qemu-img create chooses. > > However, other images exist where the geometry is set to the maximum > (65535/16/255), but the actual image size is larger. Until now, such > images are truncated at 127 GB when opening them with qemu. > > This patch changes the vpc driver to ignore geometry in this case and > only trust the size field in the header. > > Signed-off-by: Kevin Wolf <kwolf@redhat.com> > [PL: Fixed maximum geometry in the commit msg] > Signed-off-by: Peter Lieven <pl@kamp.de> > --- > block/vpc.c | 10 ++++------ > 1 file changed, 4 insertions(+), 6 deletions(-) Reviewed-by: Max Reitz <mreitz@redhat.com>
diff --git a/block/vpc.c b/block/vpc.c index c8e17cb..1c9592c 100644 --- a/block/vpc.c +++ b/block/vpc.c @@ -215,12 +215,10 @@ static int vpc_open(BlockDriverState *bs, QDict *options, int flags, bs->total_sectors = (int64_t) be16_to_cpu(footer->cyls) * footer->heads * footer->secs_per_cyl; - /* images created with disk2vhd report a far higher virtual size - * than expected with the cyls * heads * sectors_per_cyl formula. - * use the footer->size instead if the image was created with - * disk2vhd. - */ - if (!strncmp(footer->creator_app, "d2v", 4)) { + /* Images that have exactly the maximum geometry are probably bigger and + * would be truncated if we adhered to the geometry for them. Rely on + * footer->size for them. */ + if (bs->total_sectors == 65535ULL * 16 * 255) { bs->total_sectors = be64_to_cpu(footer->size) / BDRV_SECTOR_SIZE; }