Re: [Qemu-devel] [RFC PATCH] vpc: Ignore geometry for large images

[Kevin Wolf]

Am 10.02.2015 um 12:41 hat Peter Lieven geschrieben:
> Am 09.02.2015 um 17:09 schrieb Kevin Wolf:
> >The CHS calculation as done per the VHD spec imposes a maximum image
> >size of ~127 GB. Real VHD images exist that are larger than that.
> >
> >Apparently there are two separate non-standard ways to achieve this:
> >You could use more heads than the spec does - this is the option that
> >qemu-img create chooses.
> >
> >However, other images exist where the geometry is set to the maximum
> >(65536/16/255), but the actual image size is larger. Until now, such
> >images are truncated at 127 GB when opening them with qemu.
> >
> >This patch changes the vpc driver to ignore geometry in this case and
> >only trust the size field in the header.
> >
> >Signed-off-by: Kevin Wolf <address@hidden>
> >---
> >
> >Peter, I'm replacing some of your code in the hope that the new approach
> >is more generally valid. Of course, I haven't tested if your case with
> >disk2vhd is still covered. Could you check this, please?
> 
> I checked this and found that disk2vhd always sets CHS to 65535ULL * 16 * 255
> independed of the real size.
> 
> But, as the conversion to CHS may have an error its maybe the best solution
> to ignore CHS completely and always derive total_sectors from footer->size 
> unconditionally.
> 
> I had a look at what virtualbox does and they only rely on footer->size. If 
> they
> alter the size or create an image the write the new size into the footer and 
> recalculate
> CHS by the formula found in the appendix of the original spec.
> 
> Check vhdCreateImage, vhdOpen in 
> http://www.virtualbox.org/svn/vbox/trunk/src/VBox/Storage/VHD.cpp
> 
> The original spec also says that CHS values purpose is the use in an ATA 
> controller only.

The problem with just using footer->size back then when I implemented
this was that from the perspective of a VirtualPC guest run in qemu, the
size of its hard disk would change, which you don't want either. Going
from VPC to qemu would be ugly, but mostly harmless as the disk only
grows. But if you use an image in qemu where the disk looks larger and
then go back to VPC which respects geometry, your data may be truncated.

Kevin