From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1OBPe5-0007cX-4p
	for qemu-devel@nongnu.org; Mon, 10 May 2010 05:51:29 -0400
Received: from [140.186.70.92] (port=38264 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OBPdy-0007Y7-Og
	for qemu-devel@nongnu.org; Mon, 10 May 2010 05:51:28 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <kwolf@redhat.com>) id 1OBPdo-0005Oa-MR
	for qemu-devel@nongnu.org; Mon, 10 May 2010 05:51:22 -0400
Received: from mx1.redhat.com ([209.132.183.28]:46231)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <kwolf@redhat.com>) id 1OBNiz-0007LJ-SN
	for qemu-devel@nongnu.org; Mon, 10 May 2010 03:48:26 -0400
Message-ID: <4BE7BA2B.103@redhat.com>
Date: Mon, 10 May 2010 09:47:55 +0200
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
References: <4257163836-BeMail@laptop> <4BE68BAF.4040700@mail.berlios.de>
In-Reply-To: <4BE68BAF.4040700@mail.berlios.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH] vdi: Fix image opening and creation for
	odd disk sizes
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Weil <weil@mail.berlios.de>
Cc: =?UTF-8?B?RnJhbsOnb2lzIFJldm9s?= <revol@free.fr>, qemu-devel@nongnu.org

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