From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1OB3Zh-0006QV-4C for qemu-devel@nongnu.org; Sun, 09 May 2010 06:17:29 -0400 Received: from [140.186.70.92] (port=36968 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OB3Ze-0006PH-Tw for qemu-devel@nongnu.org; Sun, 09 May 2010 06:17:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OB3Zd-0007qm-2l for qemu-devel@nongnu.org; Sun, 09 May 2010 06:17:26 -0400 Received: from moutng.kundenserver.de ([212.227.17.9]:61410) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OB3Zc-0007qg-LP for qemu-devel@nongnu.org; Sun, 09 May 2010 06:17:25 -0400 Message-ID: <4BE68BAF.4040700@mail.berlios.de> Date: Sun, 09 May 2010 12:17:19 +0200 From: Stefan Weil MIME-Version: 1.0 References: <4257163836-BeMail@laptop> In-Reply-To: <4257163836-BeMail@laptop> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [Qemu-devel] Re: [PATCH] vdi: Fix image opening and creation for odd disk sizes List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?RnJhbsOnb2lzIFJldm9s?= Cc: Kevin Wolf , qemu-devel@nongnu.org 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