mkimg: Add flexible partition size

[manu]

Summary

Partition size can now be specified in percent.
Actual size is calculated according to the total of available blocks on
the disk minus the ones used for the scheme metadata.
One can create a 'fill' partition, one that will take all the remaining
space on the disk, using '~' for the size.

Sponsored-By: Gandi.net

[marcel]

usr.bin/mkimg/mkimg.c

418

I don't understand this and comes across as wrong. We can accurately calculate the number of metadata sectors, so why do we need to randomly add a sector?

424

I don't think this is correct. The EBR scheme has a sector of metadata before every partition.

426

diskblock is a poorly chosen name. Please use something like "usable_size" or something like that.

444

Didn't we add the percentage form for fill partitions?

[manu]

usr.bin/mkimg/mkimg.c

418

The problem is rounding errors in the percentage calculation, I'll fix that (didn't occur to me before ..)

424

Mhm ok, I'll check that.

426

Will do.

444

No. the usage I have for this is for something like that :
mkimg --capacity ${SIZE} -o img -s gpt -p freebsd-swap::~ -p ntfs:=somedata

Where $SIZE is randomly choosen by a scripts.

[marcel]

usr.bin/mkimg/mkimg.c

444

But isn't that equivalent to:

mkimg --capacity ${SIZE} -o img -s gpt -p freebsd-swap::100% -p ntfs:=somedata

The whole reason for using a percentage is that you can also say:

mkimg --capacity ${SIZE} -o img -s gpt -p freebsd-ufs::50% -p freebsd-ufs::50%

[manu]

usr.bin/mkimg/mkimg.c

444

No,
percentage is calculated on the whole disk, so your first example will throw an error because the first partition took the whole space.
Your second usage is fine and works (and it's basically the example in the manpages)

[marcel]

usr.bin/mkimg/mkimg.c

444

Hence my review comment. The percentage is hardly useful if and when you have actual partitions, because a partition can only be created by taking from unused space and if the percent applies to the entire disk (including used space), then it can't be used to define the size without causing a lot of confusion.

[manu]

usr.bin/mkimg/mkimg.c

444

So you're suggesting that percent calculation should be on entire disk minus the size-defined (either file or literal size) partitions ?

[marcel]

usr.bin/mkimg/mkimg.c

444

Correct. It's should even be possible to support PIPEd partitions, provided there are no fill partitions preceding it. But it's ok to defer that particular use case for later, or even have someone else worry about that.

The logic could be something like the following:

1. Iterate the partition list and save the index of the first occurrence of either the pipe partition and the fill partition. Let's say that the index for a partition type will be -1 if no such partitions are in the list. For every fill partition, add the fraction (= percentage) to a running total.
2. If there's no maximum disk size, emit an error if the index of the first fill partition is not -1. We can't have fill partitions if we don't have a maximum size.
3. If there's a maximum size, emit an error if the index of the first fill partition is smaller than the index of the first pipe partition and the index of the fill partition is not -1. We don't support pipe partitions and fill partitions (more precisely, we can't support pipe partitions if they follow one or more fill partitions).
4. If there are fill partitions, emit an error if the total fraction (= percentage) is larger than 100. It's ok if not all unallocated space is assigned to fill partitions, but we can never assign more than what we have unallocated.
5. If the have fill partitions (the index is not -1), determine the offset and sizes of all partitions with the caveat that fill partitions have a size of 0. This means that partitions that follow fill partitions don't have the right offset to begin with. This gives us the total number of blocks (not sectors) of unallocated space.
6. If there are fill partitions and there are unallocated blocks (not sectors), divide the blocks among the fill partitions according to the fraction (= percentage). If the total fraction is 100, give any left-over blocks to the last fill partition as a way to handle rounding errors. If the total fraction is not 100, rounding doesn't need to be handled, because there will unallocated blocks left. One more or one less unallocated block is not a problem.
7. If there are fill partitions, then they now has a final size, which means we can finalize the offsets of all partitions.
8. Load partitions as currently done. Partitions may or may not have an offset and size already. If not, set the offset before loading to the current block address and set the size after loading the data. Otherwise make sure the offset matches the current block address before loading and make sure the size matches after loading.
9. etc...

To support pipe partitions and fill partitions, the logic will be slightly different. Some partitions may be loaded before others are sized/placed. However, the overall logic as described above will still hold.

[wblock]

usr.bin/mkimg/mkimg.1

354

s/support/supports/

Probably works better with "flexibly-sized", too.

355

s/have/has/

Please start new sentences on new lines. The second sentence is simpler as two, also:

has been provided.
Flexible sizes are given as percentages.
The actual size is calculated as the given percent of the entire disk capacity.

359

Please avoid using the informal "you" and "your".

A tilde (~) can be given as a size, specifying that the partition
is to use the entire remaining capacity.

362

Please avoid the informal "you" and "your". "Note" is usually redundant:

Fill partitions cannot be used with cascaded partitions.

usr.bin/mkimg/mkimg.c

175

Guidelines say to use "manual page". I'm open-minded about that, but this should be two words "man page" if the shorter form is used.

416

* Calculate the number of usable blocks on the disk after
* subtracting scheme metadata