>>> On 2/6/2012 at 09:51 AM, in message <4f3004fc.7070...@redhat.com>, Kevin
>>> Wolf
<kw...@redhat.com> wrote:
> Am 06.02.2012 17:22, schrieb Charles Arnold:
>>>>> On 2/6/2012 at 08:46 AM, in message <4f2ff5b9.9090...@redhat.com>, Kevin
>>>>> Wolf
>> <kw...@redhat.com> wrote:
>>>
>>> Somehow you lost the ret = -EFBIG here.
>>>
>>> Otherwise the patch looks good enough for me.
>>>
>>> Kevin
>>
>> Thanks Kevin. Here is the revised patch with just this fix.
>> - Charles
>
> Thanks, applied to the block branch.
>
> I have one question left, though:
>
>> + total_sectors = total_size / BDRV_SECTOR_SIZE;
>> + if (disk_type == VHD_DYNAMIC) {
>> + /* Calculate matching total_size and geometry. Increase the number
> of
>> + sectors requested until we get enough (or fail). */
>> + for (i = 0; total_sectors > (int64_t)cyls * heads * secs_per_cyl;
>> + i++) {
>> + if (calculate_geometry(total_sectors + i,
>> + &cyls, &heads, &secs_per_cyl)) {
>> + ret = -EFBIG;
>> + goto fail;
>> + }
>> + }
>> + } else {
>> + if (calculate_geometry(total_sectors, &cyls, &heads,
>> &secs_per_cyl)) {
>> + ret = -EFBIG;
>> + goto fail;
>> + }
>> + }
>
> What's the reason that we need to do things differently here depending
> on the subformat? Dynamic disks round up the size so that during image
> conversion images won't be truncated. For fixed images,
> calculate_geometry can round down, so don't fixed image have the same
> problem?
Yes. In my testing I was simply creating a fixed disk that would appear exactly
as
it does when an equivalent size was created on windows. I did not factor in
the rounding needed on convert in order to get the right number of sectors
to cover the total (and somewhat arbitrary) size of the disk.
Combining them means that we will usually round up a little bit even on create
which I suppose is fine.
- Charles
