#1750 Issue closed: Replace old 430_autoresize_all_partitions code by a new and proper 410_autoresize_all_partitions¶

Labels: enhancement, cleanup, won't fix / can't fix / obsolete

jsmeix opened issue at 2018-03-08 11:05:¶

Since https://github.com/rear/rear/pull/1733
the old 400_autoresize_disks code with its issues
https://github.com/rear/rear/issues/1731
https://github.com/rear/rear/issues/1718
https://github.com/rear/rear/issues/102
was moved "as is" to 430_autoresize_all_partitions.

Hereby I propose to replace that old code by a new script
layout/prepare/default/410_autoresize_all_partitions.sh
that implements the basic idea of the old code properly
in particular with support for a new config variable
AUTORESIZE_PARTITIONS_ALIGN_BLOCK_SIZE
with same meaning as USB_PARTITION_ALIGN_BLOCK_SIZE.

The reason why 410_autoresize_all_partitions will be run
directly before 420_autoresize_last_partitions is that this way
the code in 410_autoresize_all_partitions could be much simpler
because it could "just resize" the partitions and "just align" them
without the need for sophisticated checks that the last partition
does not exceed the end of the new disk by a single byte.

When 410_autoresize_all_partitions "just resizes" and "just aligns" the partitions
with AUTORESIZE_PARTITIONS_ALIGN_BLOCK_SIZE the last partition may
exceed the end of the new disk at most by something about
number_of_partitions * AUTORESIZE_PARTITIONS_ALIGN_BLOCK_SIZE
which is usually at most some MiBs.

After 410_autoresize_all_partitions was run the last partition may exceed
the end of the new disk but the subsequent 420_autoresize_last_partitions
would safely shrink the last partition up to the end of the new disk
where 'safely' means with all its limits and error checking that should
avoid that a last partition gets automatically shrinked too much.

In particular for users with many GPT partitions and a small last partition
(or with many logical partitions and a small last partition)
the automated resizing and re-alingment of all partitions
may not "just work" so that "rear recover" would error out
when the (small) last partition would have to be shrinked too much.

jsmeix commented at 2020-03-06 13:53:¶

Because there is zero user request for such a functionality
I won't implement it.

---

[Export of Github issue for rear/rear.]