[vbox-dev] vdiRead and vdiWrite asserts question

[Ribhi Kamal]

Thanks, I'll change the caller to discard the last block and write a
warring to the release log.



On Tue, Jun 4, 2013 at 1:26 PM, Klaus Espenlaub
<klaus.espenlaub at oracle.com>wrote:

> Hi Ribhi,
>
>
> On 04.06.2013 17:51, Ribhi Kamal wrote:
>
>> Thanks Klaus,
>> There is nothing wrong with vboxmanage, its just that the API doesn't
>> have these functions.
>>
>> As for the raw disk image, the block size may always be a multiple of
>> 512 bytes but the file size of the entire image may not.
>>
>
> I don't understand how you'd produce a consistent image of any disk which
> is not a multiple of 512 bytes in size...
>
>
>  For example:
>> dd if=/dev/zero of=test.img count=2 bs=1MB
>> In this case the last 128 bytes are not usable but the entire image is
>> valid. convertfromraw asserts, in debug, on the last block.
>>
>
> Yes, files can be any size. Sensible raw disk images cannot. So they will
> never be exactly 2000000 bytes in size, they'd be either 1999872 bytes or
> 2000384 bytes. Anything else needs better explanations than what I saw so
> far.
>
>
>  These asserts are obviously not an issue, since they are only active in
>> debug. I just wanted to know if I can safely disable these asserts.
>>
>
> No, don't disable these asserts, they are there for a purpose. Fix the
> caller to pass multiples of 512 bytes (and also reads multiples of 512
> bytes), similarly the offset must be a multiple of the sector size. Even
> better, convince whoever produces such odd sized disk images that they're
> doing something wrong.
>
> The code is not designed to handle writes which are not a multiple of the
> sector size, and even for reads I wouldn't make any bets. Neither will
> probably fail straight away or in obvious ways, but I'm quite sure that it
> will create VDI files which are not meeting the assumptions in various
> places of the code, so they can cause unexpected failures. For example when
> the VM then wants to read the final sector (it will always read multiples
> of 512 bytes), and bumps into an EOF error.
>
> Klaus
>
>  On Tue, Jun 4, 2013 at 5:11 AM, Klaus Espenlaub
>> <klaus.espenlaub at oracle.com <mailto:klaus.espenlaub@**oracle.com<klaus.espenlaub at oracle.com>>>
>> wrote:
>>
>>     Hi Ribhi,
>>
>>     On 03.06.2013 23:25, Ribhi Kamal wrote:
>>      > I'm messing around with adding some conversions of raw to/from
>>     virtual
>>      > disks to the API and noticed that the functions vdiRead and
>>     vdiWrite (in
>>      > VDI.cpp) assert whenever the amount being read/written is not a
>>     multiple
>>      > of 512.
>>
>>     Anything wrong with VBoxManage convertfromraw and/or clonehd? The
>>     functionality should be there already.
>>
>>      > Do these functions break when the byte count is not a multiple of
>>     512 or
>>      > is this just a sanitary check?
>>
>>     The code is meant to implement a block device interface with fixed
>>     sector size, and thus the parameter sanity checking is consistent with
>>     this intention. I don't care if the code could theoretically handle
>> such
>>     cases, it's not meant to get such requests ever.
>>
>>      > Are these asserts valid when dealing with binary image files
>>     (they could
>>      > have any size) vs block devices?
>>
>>     I don't understand... raw disk image files should always be a multiple
>>     of the sector size, and if that's not the case it's a rather clear
>> hint
>>     that the file was corrupted during transfer.
>>
>>     Klaus
>>
>>      >
>>      > Thanks,
>>      > -- Ribhi
>>
>>     ______________________________**_________________
>>     vbox-dev mailing list
>>     vbox-dev at virtualbox.org <mailto:vbox-dev at virtualbox.**org<vbox-dev at virtualbox.org>
>> >
>>
>>     https://www.virtualbox.org/**mailman/listinfo/vbox-dev<https://www.virtualbox.org/mailman/listinfo/vbox-dev>
>>
>>
>>
>>
>> --
>> -- Ribhi
>>
>


-- 
-- Ribhi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20130604/e82b8782/attachment.html>