[vbox-dev] VMDK inflation and grain alignment/padding

[Christian Svensson]

On Thu, Feb 18, 2016 at 4:35 PM, Michal Necasek <michal.necasek at oracle.com>
wrote:

>   According to my reading of it, qemu-img produced an rater suspect
> image. You have a supposedly 64K grain but after decompression, there is
> only 49K of data. That's obviously a problem because what do you do with
> the missing 15K? You could make something up, but what? Zeros? All bits
> set? Random noise? There's no good answer.
>

Well, do you need to make something up?


>
>   If I understood it correctly, in your case the inconsistent grain
> occurs at the end of the disk. Does that mean that the size of the disk
> in grains is larger than the size in sectors?
>

I think so. I'll verify, but VMware showed some pretty funky numbers for
capacity.


>   At the end of a disk it would be possible to guess "what the user
> wanted" but if such a grain occurred in the middle, how do you deal with
> it?
>

I'm not convinced that you need to. Isn't the image integrity is on the
user, and if it is why does VBox care about doing arbitrary checks about
data integrity? For OVA we have manifest files to verify the integrity for
example.
Would simply decompressing all the grains and appending them to each other
be acceptable?

  It might be interesting to check what VMware actually did with it --
> what happened with the missing 15K of data? Is it actually in the
> imported disk or not?
>

I'll try to get some data on this if it would help getting a decision.
Should be simple enough.


>   To be fair you probably asked qemu-img to do an impossible task. The
> grain size must be a power of two and greater than 4K, but your disk
> image apparently has a size that's not even a multiple of 2K. The VMDK
> spec also says that the capacity of the disk (extent) should be a
> multiple of the grain size. So you created a disk image that cannot be
> very well be represented as a VMDK.
>

If this is true qemu-img should be made to complain, not create a "broken"
VMDK. The fact that VMware products seem to be able to parse them would
possibly imply a grandfather rule. I'm open for rising the question with
qemu, but if VBox can be made to handle these images I think that makes
more sense. "Be strict when generating output, be liberal when accepting
input" -- Sombody somewhere.

Thanks,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20160218/9959236d/attachment.html>