Patchwork vdi: Fix image opening and creation for odd disk sizes

login
register
mail settings
Submitter Stefan Weil
Date May 6, 2010, 6:29 p.m.
Message ID <1273170570-20087-1-git-send-email-weil@mail.berlios.de>
Download mbox | patch
Permalink /patch/51860/
State New
Headers show

Comments

Stefan Weil - May 6, 2010, 6:29 p.m.
This patch fixes a regression introduced by commit
95a2f9bc588c3f83375d87b0a9394f89a1bcfada.

The fix is based on a patch from Kevin Wolf. Here his comment:

"The number of blocks needs to be rounded up to cover all of the virtual hard
disk. Without this fix, we can't even open our own images if their size is not
a multiple of the block size."

While Kevin's patch addressed vdi_create, my modification also fixes
vdi_open which now accepts any image which is large enough to hold
the blocks.

I also decided to keep the original code in vdi_create which rounds down.
Rounding works in both directions, and there are good arguments for both,
so I just left the original simple code.

It is very important to use the rounded value for the new disk size, too -
otherwise VirtualBox cannot open our disk image.

Cc: Kevin Wolf <kwolf@redhat.com>
Cc: François Revol <revol@free.fr>
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
---
 block/vdi.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)
Kevin Wolf - May 7, 2010, 7:55 a.m.
Am 06.05.2010 20:29, schrieb Stefan Weil:
> This patch fixes a regression introduced by commit
> 95a2f9bc588c3f83375d87b0a9394f89a1bcfada.
> 
> The fix is based on a patch from Kevin Wolf. Here his comment:
> 
> "The number of blocks needs to be rounded up to cover all of the virtual hard
> disk. Without this fix, we can't even open our own images if their size is not
> a multiple of the block size."
> 
> While Kevin's patch addressed vdi_create, my modification also fixes
> vdi_open which now accepts any image which is large enough to hold
> the blocks.

Shouldn't it be the other way round? That is, an image which has some
unused blocks at its end makes sense, whereas an image with a virtual
disk size that can't be represented with the number of blocks doesn't?

> I also decided to keep the original code in vdi_create which rounds down.
> Rounding works in both directions, and there are good arguments for both,
> so I just left the original simple code.
> 
> It is very important to use the rounded value for the new disk size, too -
> otherwise VirtualBox cannot open our disk image.

So you're saying that in VDI you can't represent disks with an odd size?
The one thing common across image formats seems to be that they are
broken...

Kevin
François Revol - May 7, 2010, 11:55 a.m.
Le Fri, 07 May 2010 09:55:23 +0200, Kevin Wolf a écrit :
> Am 06.05.2010 20:29, schrieb Stefan Weil:
> > This patch fixes a regression introduced by commit
> > 95a2f9bc588c3f83375d87b0a9394f89a1bcfada.
> > 
> > The fix is based on a patch from Kevin Wolf. Here his comment:
> > 
> > "The number of blocks needs to be rounded up to cover all of the 
> > virtual hard
> > disk. Without this fix, we can't even open our own images if their 
> > size is not
> > a multiple of the block size."
> > 
> > While Kevin's patch addressed vdi_create, my modification also 
> > fixes
> > vdi_open which now accepts any image which is large enough to hold
> > the blocks.
> 
> Shouldn't it be the other way round? That is, an image which has some
> unused blocks at its end makes sense, whereas an image with a virtual
> disk size that can't be represented with the number of blocks 
> doesn't?

Exactly, else you don't create what you are asked for.

> > I also decided to keep the original code in vdi_create which rounds 
> > down.
> > Rounding works in both directions, and there are good arguments for 
> > both,
> > so I just left the original simple code.
> > 
> > It is very important to use the rounded value for the new disk 
> > size, too -
> > otherwise VirtualBox cannot open our disk image.
> 
> So you're saying that in VDI you can't represent disks with an odd 
> size?
> The one thing common across image formats seems to be that they are
> broken...

VB works quite well with my converted laptop image which indeed doesn't 
end on block boundary.

Was it because you were just setting size larger than the covered by 
the blocks ?

François.
Stefan Weil - May 9, 2010, 10:17 a.m.
Am 07.05.2010 13:55, schrieb François Revol:
> Le Fri, 07 May 2010 09:55:23 +0200, Kevin Wolf a écrit :
>> Am 06.05.2010 20:29, schrieb Stefan Weil:
>>> This patch fixes a regression introduced by commit
>>> 95a2f9bc588c3f83375d87b0a9394f89a1bcfada.
>>>
>>> The fix is based on a patch from Kevin Wolf. Here his comment:
>>>
>>> "The number of blocks needs to be rounded up to cover all of the
>>> virtual hard
>>> disk. Without this fix, we can't even open our own images if their
>>> size is not
>>> a multiple of the block size."
>>>
>>> While Kevin's patch addressed vdi_create, my modification also
>>> fixes
>>> vdi_open which now accepts any image which is large enough to hold
>>> the blocks.
>>
>> Shouldn't it be the other way round? That is, an image which has some
>> unused blocks at its end makes sense, whereas an image with a virtual
>> disk size that can't be represented with the number of blocks
>> doesn't?
>
> Exactly, else you don't create what you are asked for.
>
>>> I also decided to keep the original code in vdi_create which rounds
>>> down.
>>> Rounding works in both directions, and there are good arguments for
>>> both,
>>> so I just left the original simple code.
>>>
>>> It is very important to use the rounded value for the new disk
>>> size, too -
>>> otherwise VirtualBox cannot open our disk image.
>>
>> So you're saying that in VDI you can't represent disks with an odd
>> size?
>> The one thing common across image formats seems to be that they are
>> broken...
>
> VB works quite well with my converted laptop image which indeed doesn't
> end on block boundary.
>
> Was it because you were just setting size larger than the covered by
> the blocks ?
>
> François.

Kevin and you are right, and my interpretation of disk_size was wrong.

disk_size is not the size used for the blocks (then it would have to be
large enough to keep all blocks).

disk_size is the number of bytes which are really used for data
(so it is less or equal blocks_in_image * 1 MiB). VBoxManage
allows creation of disk images which use the last block only partially,
something I did not know up to now.

Kevin's patch is correct but still incomplete. VBoxManage can
create images with really odd disk sizes (even sizes which are not
a multiple of the sector size), so the checks in vdi_open
need modifications. The current code also fails for read or write
access beyond the last block.

So I'll send a new patch...

Regards
Stefan
Kevin Wolf - May 10, 2010, 7:47 a.m.
Am 09.05.2010 12:17, schrieb Stefan Weil:
> Kevin and you are right, and my interpretation of disk_size was wrong.
> 
> disk_size is not the size used for the blocks (then it would have to be
> large enough to keep all blocks).
> 
> disk_size is the number of bytes which are really used for data
> (so it is less or equal blocks_in_image * 1 MiB). VBoxManage
> allows creation of disk images which use the last block only partially,
> something I did not know up to now.

Ok. Makes a lot more sense this way.

> Kevin's patch is correct but still incomplete. VBoxManage can
> create images with really odd disk sizes (even sizes which are not
> a multiple of the sector size), so the checks in vdi_open
> need modifications. The current code also fails for read or write
> access beyond the last block.

Not sure what the semantics of such images is. Disk emulation should
only access complete sectors, and the qemu block layer works with
sectors, too. How does VBox implement this? Is the size rounded for the
virtual disk size? And in what direction?

Kevin

Patch

diff --git a/block/vdi.c b/block/vdi.c
index 1d257b4..2213819 100644
--- a/block/vdi.c
+++ b/block/vdi.c
@@ -414,8 +414,8 @@  static int vdi_open(BlockDriverState *bs, int flags)
     } else if (header.block_size != 1 * MiB) {
         logout("unsupported block size %u B\n", header.block_size);
         goto fail;
-    } else if ((header.disk_size + header.block_size - 1) / header.block_size !=
-               (uint64_t)header.blocks_in_image) {
+    } else if (header.disk_size < 
+               (uint64_t)header.blocks_in_image * header.block_size) {
         logout("unexpected block number %u B\n", header.blocks_in_image);
         goto fail;
     } else if (!uuid_is_null(header.uuid_link)) {
@@ -827,7 +827,10 @@  static int vdi_create(const char *filename, QEMUOptionParameter *options)
         return -errno;
     }
 
+    /* VirtualBox wants a disk size which is a multiple of the block size. */
     blocks = bytes / block_size;
+    bytes = blocks * block_size;
+
     bmap_size = blocks * sizeof(uint32_t);
     bmap_size = ((bmap_size + SECTOR_SIZE - 1) & ~(SECTOR_SIZE -1));