Comment 5 for bug 1991083

tl;dr: add a 10% margin to the current minimal size estimate

As far as I can tell, the issue originates in get_ext2_resize_range() in ubiquity/d-i/source/partman-partitioning/lib/resize.sh . The function parses the output from `tune2fs -l` in order to find the total number of blocks and the number of free blocks; it then uses the difference as the number of used blocks which gets multiplied by the block size to get the used space.

However, resize2fs disagrees. It also outputs the minimal number of blocks which is a fair bit higher than what had been computed by get_ext2_resize_range(). Resize2fs provides an estimate and it might be wrong but since obviously it is not going to accept anything lower than what is has determined, there is little point in not using its output value.

Unfortunately, resize2fs errors out immediately if the filesystem has not been unmounted cleanly (enough?). I don't know how ubiquity handles resizing of partition that need fsck first but in any case, I don't want to add code to run fsck before giving a size estimate.

Moreover, I don't think that it makes sense to use the absolute smallest size possible. The fact the user resizes the existing partition rather than overwriting it denotes a will to keep the other system working. If it gets shrunk so much that there is no free space, it's not going to be working well anymore. That can't be the user's intent.

I believe it is best to keep the current estimate but so something like multiplying it by 1.1 or even 1.05. The current estimate is quite off compared to what resize2fs outputs so it might need a bit of improvement too. I'll try to gather stats for various filesystems.

I haven't checked yet if that applied to anything else than ext* filesystems.