[vbox-dev] vhd resize corruption

[Alexander Eichner]

Hi Aaron,

finally found the bug. The corruption was caused by to a missing cast and resulting in an integer overflow later on.
The fix will be part of the next maintenance release.

Regards,
Alexander Eichner

On 10.09.2014 20:01, Alexander Eichner <alexander.eichner at oracle.com> wrote:

> Hi Aaron,
> 
> thanks for the images, I’ll have a look at them.
> We are definitely interested in data corruption issues but because we are a small team with lots of work
> it might take a while to get a response sometimes as we are working on other issues. Besides, I was on vacation last week and didn’t watch
> mails closely.
> 
> I’ll see what I can find out from your images.
> 
> Regards,
> Alexander Eichner
> 
> On 10.09.2014 19:56, Aaron Brice <aaron.brice at datasoft.com> wrote:
> 
>> On 09/09/2014 01:35 AM, Alexander Eichner wrote:
>>> Hi Aaron,
>>> 
>>> (please keep the topic on the list)
>> 
>> Sorry, I had unsubscribed from the list when it didn't seem like anyone was interested in data corruption issues..
>> 
>>> 
>>> I tested the code by writing random data to it, resizing the image and verifying that the disk content didn’t changed by reading and comparing the data.
>>> 
>>> Resizing is a quick operation because VBox just relocates the data blocks which would be overwritten by the extended BAT. The data blocks are appended to the image file and
>>> in most cases only one block needs to be relocated. If you still ave the original and the broken VHD image file around can you please mail me the first 5MB of each image so
>>> I can have a look at them?
>> 
>> I didn't backup the original.  However, I wrote this script to resize my broken .vhd back down to the original size: https://gist.github.com/ambrice/c36b46237fcc979d80c9
>> 
>> I'm not 100% sure after running that script that it was back to the original state, for example I didn't adjust the drive geometry fields.  However after running that, "vhd-util check" from the blktap-utils package says it's valid, whereas before it was complaining that "block 0 (offset 0xa3) clobbers headers".  So I then cloned it to a .vdi and resized the .vdi and that worked (after running the Windows 7 repair to restore the partition table and boot manager).
>> 
>> So I have a valid 40GB .vhd which may not match the original 100%, but I just tried to resize it to 60GB again and ran into the same problem.  I ran: VBoxManage modifyhd AaronVM.vhd --resize 61440
>> 
>> It got quickly to 100% with no errors, and the file size didn't change at all (40766087168 bytes before and after).  Attached are the first 5MB of the file before and after the resize.
>> 
>> Thanks,
>> Aaron
>> 
>> <after.vhd.xz><before.vhd.xz>
>