ptgen: don’t insert CHS gap head in MBR partition tables #12
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When
ptgen
is aligning partitions on a specific kB boundary (-l
option; OpenWrt uses 256kB for x86, but other, larger values for some other architectures) and creating an MBR-type partition table (-g
option absent), it was inserting an extra head’s worth of gap between partitions.For example, in the x86 case, where OpenWrt builds an image using
-h 16 -s 63
, consisting of 16MB and 104MB partitions by default, and 256kB alignment,ptgen
produced:Notice the 512-sector gap between the end of the first partition and the start of the second, despite the fact that sector 33280 (which immediately follows the first partition) would have been 256kB-aligned. This occurred because
ptgen
inserted a gap equal to one CHS head before 256kB-aligning the second partition. In this 63 sector/head geometry requested when OpenWrt builds an image, this gap results in 32,256 bytes of waste, which after kB-aligning, becomes 256kB of waste.The expected layout, which is produced after this patch:
This gapless layout more closely resembles the layout when
ptgen
is used in GPT (-g
) mode.The 1-head gap between partitions in head-aligning mode (no
-l
) also appears to be unnecessary. The sole function of this gap seems to be to force the first partition to begin at the first sector of the second head rather than the first head, which would have resulted in a collision because the MBR partition table resides there. With this change, a different approach is taken, in which the first partition’s position is set more directly to the start of the first head, without affecting subsequent partitions. This eliminates the 32,256-byte gap between partitions in this mode. Note that when head-aligning, each partition’s size is padded as needed so as to consume an entire head, so any subsequent partition will still be head-aligned. In OpenWrt, only gemini/dlink_dns-313 and layerscape sdcard images useptgen
to produce a non-kB-aligned MBR partition table, and it doesn’t appear that either will be negatively impacted by this change.