From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1OANSu-0006EO-Tq for qemu-devel@nongnu.org; Fri, 07 May 2010 09:19:41 -0400 Received: from [140.186.70.92] (port=59139 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OANSl-0004Zi-Mw for qemu-devel@nongnu.org; Fri, 07 May 2010 09:19:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OAM94-0006qO-AO for qemu-devel@nongnu.org; Fri, 07 May 2010 07:55:07 -0400 Received: from smtp6-g21.free.fr ([212.27.42.6]:49324) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OAM93-0006oc-NN for qemu-devel@nongnu.org; Fri, 07 May 2010 07:55:06 -0400 In-Reply-To: <4BE3C76B.3020301@redhat.com> From: "=?utf-8?q?Fran=C3=A7ois?= Revol" Date: Fri, 07 May 2010 13:55:04 +0200 CEST Message-Id: <4257163836-BeMail@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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: Kevin Wolf Cc: qemu-devel@nongnu.org Le Fri, 07 May 2010 09:55:23 +0200, Kevin Wolf a =C3=A9crit : > 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=5Fcreate, my modification also > > fixes > > vdi=5Fopen which now accepts any image which is large enough to hold > > the blocks. > > Shouldn't it be the other way round=3F 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=3F Exactly, else you don't create what you are asked for. > > I also decided to keep the original code in vdi=5Fcreate 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=3F > 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 =3F Fran=C3=A7ois.