Date: Sat, 28 Jan 2017 19:25:23 +0200 From: Toomas Soome <tsoome@me.com> To: Warner Losh <imp@bsdimp.com> Cc: Julian Elischer <julian@freebsd.org>, Ngie Cooper <yaneurabeya@gmail.com>, Allan Jude <allanjude@freebsd.org>, FreeBSD Current <current@freebsd.org> Subject: Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat Message-ID: <DE64D0B3-6797-4ADB-9F7E-DF815971018D@me.com> In-Reply-To: <CANCZdfqdZumJvRcHGmZR_9s-ULFWsvp7h91H39o4nPgyqPBooA@mail.gmail.com> References: <A33154F2-70E1-4047-8496-7D4D85CFF292@gmail.com> <EF719374-BF9D-44EF-9F45-53B2B506047C@me.com> <CANCZdfrzOr3YdbAKRrwUXsFDhdQ3hErf1vbYSG7MdpV_m%2B=YRQ@mail.gmail.com> <EB309E42-BEA6-49DF-BF34-172076851891@gmail.com> <f251f193-0fcd-cb2d-0fff-c443c4ca49d6@freebsd.org> <CANCZdfqdZumJvRcHGmZR_9s-ULFWsvp7h91H39o4nPgyqPBooA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 28. jaan 2017, at 18:56, Warner Losh <imp@bsdimp.com> wrote: >=20 >>=20 >>=20 >> 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? >=20 > Hard to say. Given boot1/boot2 growth over time, I'd peg that close to = 100%. >=20 >=20 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 =E2=80=9Cbloat=E2=80=9D is appearing - to be able to = implement some things, the =E2=80=9Cthin=E2=80=9D implementations are = just not enough, or some =E2=80=9Cunexpected=E2=80=9D 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DE64D0B3-6797-4ADB-9F7E-DF815971018D>