> On 28. jaan 2017, at 18:56, Warner Losh <i...@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;)

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to