Libguestfs - Sep 2015 - Wrong deficit calculation in virt-resize.

Hello guys!

I tried to shrink a partition when resizing an image using virt-resize. 
The numbers and result are weird.

================BEFORE===============
 ><fs> blockdev-getsize64 /dev/sdc
4294967296

 ><fs> part-list /dev/sdc
[0] = {
   part_num: 1
   part_start: 65536
   part_end: 2193555455
   part_size: 2193489920
}
[1] = {
   part_num: 2
   part_start: 2193555456
   part_end: 4294967295
   part_size: 2101411840
}

 ><fs> list-filesystems
/dev/sdc1: ext3
/dev/sdc2: ntfs

So I have two parititons up to image end, and 64k block at the start.

I wanted to shrink the last partition by 1MB (for test, yeah). I shrank 
the filesystem by 1MB but virt-resize refused to resize to 4095MB image 
requesting ~2MB more (the numbers you can see in log attached). So I had 
to shrink the filesystem by 4MB from original:

 ><fs> debug sh 'ntfsresize -f --info /dev/sdc2'
...
Cluster size       : 4096 bytes
Current volume size: 2097213952 bytes (2098 MB)
Current device size: 2101411840 bytes (2102 MB)
...

===============AFTER=================
Now virt-resize succeeded. But the deficit miscalculation gave its result.

 ><fs> blockdev-getsize64 /dev/sda
4293918720

 ><fs> part-list /dev/sda
[0] = {
   part_num: 1
   part_start: 65536
   part_end: 2193555455
   part_size: 2193489920
}
[1] = {
   part_num: 2
   part_start: 2193555456
   part_end: 4291690495
   part_size: 2098135040
}

So I have 2228225 bytes after last partition empty.

 ><fs> debug sh 'ntfsresize -f --info /dev/sda2'
Current volume size: 2098131456 bytes (2099 MB)
Current device size: 2098135040 bytes (2099 MB)

FS is ok, it fills the partition.

=======================================
I looked at resize.ml and saw complex calculations of GPT header/end, 
alignment overhead and so on.
I wondered whether virt-resize would create GPT on new image, but it 
didnt. Everything remained as before except empty space at the end.

So the question is: is there a bug with deficit calculation or do I miss 
anything?

-- 
Your sincerely,
Maxim Perevedentsev

On Thu, Sep 17, 2015 at 01:48:15PM +0300, Maxim Perevedentsev
wrote:
> Hello guys!
> 
> I tried to shrink a partition when resizing an image using
> virt-resize. The numbers and result are weird.
> 
> ================BEFORE===============> 
> ><fs> blockdev-getsize64 /dev/sdc
> 4294967296
> 
> ><fs> part-list /dev/sdc
> [0] = {
>   part_num: 1
>   part_start: 65536
>   part_end: 2193555455
>   part_size: 2193489920
> }
> [1] = {
>   part_num: 2
>   part_start: 2193555456
>   part_end: 4294967295
>   part_size: 2101411840
> }
> 
> ><fs> list-filesystems
> /dev/sdc1: ext3
> /dev/sdc2: ntfs
> 
> So I have two parititons up to image end, and 64k block at the start.
> 
> I wanted to shrink the last partition by 1MB (for test, yeah). I
> shrank the filesystem by 1MB but virt-resize refused to resize to
> 4095MB image requesting ~2MB more (the numbers you can see in log
> attached). So I had to shrink the filesystem by 4MB from original:
> 
> ><fs> debug sh 'ntfsresize -f --info /dev/sdc2'
> ...
> Cluster size       : 4096 bytes
> Current volume size: 2097213952 bytes (2098 MB)
> Current device size: 2101411840 bytes (2102 MB)
> ...
> 
> ===============AFTER=================> 
> Now virt-resize succeeded. But the deficit miscalculation gave its result.
> 
> ><fs> blockdev-getsize64 /dev/sda
> 4293918720
> 
> ><fs> part-list /dev/sda
> [0] = {
>   part_num: 1
>   part_start: 65536
>   part_end: 2193555455
>   part_size: 2193489920
> }
> [1] = {
>   part_num: 2
>   part_start: 2193555456
>   part_end: 4291690495
>   part_size: 2098135040
> }
> 
> So I have 2228225 bytes after last partition empty.
> 
> ><fs> debug sh 'ntfsresize -f --info /dev/sda2'
> Current volume size: 2098131456 bytes (2099 MB)
> Current device size: 2098135040 bytes (2099 MB)
> 
> FS is ok, it fills the partition.
> 
> =======================================> 
> I looked at resize.ml and saw complex calculations of GPT
> header/end, alignment overhead and so on.
> I wondered whether virt-resize would create GPT on new image, but it
> didnt. Everything remained as before except empty space at the end.
> 
> So the question is: is there a bug with deficit calculation or do I
> miss anything?
The deficit calculation always overestimates the size needed, because
that is safer than underestimating it.

Also, the shrinking path is not very well tested, and no where near as
often used as the expand path.  Images are expanded every time
virt-builder is used.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html