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
participants (2)
-
Maxim Perevedentsev -
Richard W.M. Jones