Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

> On 28. jaan 2017, at 18:56, Warner Losh <imp_at_bsdimp.com> wrote:
> 
>> 
>> 
>> at $JOB we are just testing a script that expands the root zfs partition on
>> in-field appliances by shaving a bit off swap and cannibalising a small data
>> partition we don't really use. I see we only left 64K for the boot part.
>> It's big enough for us for now, but possibly we should fix that as well.
>> We have a mirror setup for system disks so we have the ability to take each
>> system drive offline one at a time and rearrange it and then re-add the root
>> partition to the mirror.
>> What are the chances a regular gpt+ZFS (no encrypt) bootblock will grow over
>> 64K?
> 
> Hard to say. Given boot1/boot2 growth over time, I'd peg that close to 100%.
> 
> 


There are few things to consider. First of all, the job of the boot2 is actually really small - read out the loader binary by using file system specific reader code and start it; and, on bios system, provide quite simple prompt for few options. Nothing more, nothing less. So in that sense, it should not grow too much.

The problem is, from historical reasons, the boot2 programs are using their own personal support functions for IO, and that means that boot loader has some duplication of the internal API. Mostly it does not disturb us too much, but zfs is complex software and bundling some other features like GELI, does not make things more easier. So thats one aspect where the “bloat” is appearing - to be able to implement some things, the “thin” implementations are just not enough, or some “unexpected” additions are needed.

For the illumos port I actually did something different - I did build one single gptzfsboot binary, capable of handling zfs, ufs and pcfs (as those are ones needed), and using libstand. Still it does use thin version of keyboard input and screen output.

The size of such combined boot2 is (this one is including both skein and edonr):

-r--r--r--   1 root     sys       153600 jaan 24 14:08 gptzfsboot

Note, it does not have GELI, so if the same would be done for fbsd, the size would be a bit larger because of the crypto functions. But this setup also has a bit different strategy;  in case of zfs, the boot2 is *always* installed to 3.5MB zfs bootblock area and in case of ufs, either boot partition (same idea as freebsd-boot) or if the MBR+VTOC schema is used, free space between MBR partition and VTOC. Since in most cases the default boot is zfs, it means the boot size is not an issue (3.5MB is more than enough;)

rgds,
toomas