On Aug 24, 2014, at 4:31 PM, John-Mark Gurney <jmg_at_funkthat.com> wrote: >> >> With mkimg, you know exactly how many partitions you are creating >> , so you don't need to specify 128 as the number of partitions. > > Though, w/ people dd'ing images onto disks, and using growfs to grow > as necessary, we might want to allocate a few more more than the > minimum... I do agree that we want to keep sizes to a minimum... One thing I can maybe do is simply fill the empty sectors that are there because of alignment. If you add -P 4K to mkimg, then the first partition will by 4K aligned and you have about 5 sectors unused between the end of the GPT table and the first sector of the first partition. I may as well extend the table to cover those unued sectors. However, this is a pretty side-ways way to end up with a GPT table that has some extra room. Maybe having scheme- specific options for this kind of thing is not bad. At least EBR and APM have the same "problem" and the BSD disk label can also be created with more than just 8 partitions. Related: o Is there a need to create images with empty space at the end of in between partitions? o Is there a need to create partitions with specific indices (i.e. index 6 for a typical 'f' partition)? Answers to these questions could help figure this out... -- Marcel Moolenaar marcel_at_xcllnt.net
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:51 UTC