> 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
> 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;)
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"