On Mon, Sep 22, 2014 at 01:24:16PM +0000, Lucian Petrut wrote: > >> + if (cpu_to_be32(footer->type) == VHD_DIFFERENCING) { > >footer_buf is big-endian so this should be be32_to_cpu() > > My bad, I’ll fix the BE related issues.
The existing block/vpc.c code confuses beX_to_cpu() and cpu_to_beX(). I have sent a patch to fix that ("[PATCH] vpc: fix beX_to_cpu() and cpu_to_beX() confusion"). > >> + error_report("Resizing differencing vhd images is not > supported."); > >> + return -ENOTSUP; > >> + } > >> + > >> + old_bat_size = (s->max_table_entries * 4 + 511) & ~511; > >> + new_total_sectors = offset / BDRV_SECTOR_SIZE; > >> + > >> + for (index = 0; new_total_sectors > (int64_t)cyls * heads * > secs_per_cyl; > >> + index++) { > >> + if (calculate_geometry(new_total_sectors + index, &cyls, &heads, > >> + &secs_per_cyl)) { > >> + return -EFBIG; > >> + } > >> + } > >> + new_total_sectors = (int64_t) cyls * heads * secs_per_cyl; > >> + new_num_bat_entries = (new_total_sectors + s->block_size / 512) / > >> + (s->block_size / 512); > >This expression doesn't just round up, it always adds an extra block. > >Is this intentional? > >I expected the numerator for rounding up to be: > > new_total_sectors + s->block_size / 512 - 1 > > This was intended, it may just add an extra entry. Also, the number > of entries is calculated in the same way in the existing code which > creates dynamic VHDs, so I wanted to keep consistency with that > as well. Okay, if existing code already does it like this it makes sense to be consistent.
pgpyh8Q6AJ6_R.pgp
Description: PGP signature