From owner-freebsd-current@freebsd.org Sat Jan 28 17:25:28 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3968CC4A10 for ; Sat, 28 Jan 2017 17:25:28 +0000 (UTC) (envelope-from tsoome@me.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 914F614E1 for ; Sat, 28 Jan 2017 17:25:28 +0000 (UTC) (envelope-from tsoome@me.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8DC2CCC4A0F; Sat, 28 Jan 2017 17:25:28 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D63FCC4A0E for ; Sat, 28 Jan 2017 17:25:28 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6321E14E0; Sat, 28 Jan 2017 17:25:28 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OKI00F002SLO900@st13p35im-asmtp001.me.com>; Sat, 28 Jan 2017 17:25:27 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1485624327; bh=JXvU+Hhg/+Q1NHFxdcfOFcOmz9mtGXL4LOdioJaRQQo=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=q03zKoQpgV3zE+PAFOdJRxjhw4WPv0oVXd0K2UXVpw0Jcdh1ohS0YiYt2VMAOlLbR SnW9lJiR37eCvpZCNdW0S1i4ZAYgiE9DKduqPH08js++tzrlu+6p68uJJ5xxXwEhQZ GARCBsnCgOfz2MPEQ+/kuuXjGEqQyy3nwMCJjAjq9DRYlPZ7Gc35rj1N0e1W35A5Ls YXFx3hxn7J+TzkwKG+bXVA4XTQsXwrmNOovJCUDWwRFHqsU8PM4rDHF03xvKZ5aWVY PRUYNrI+Z9cOHM2S+A9RnGftEkkFLUoqoKsT1gNEdnveXs1pFxHjMIkPJtU8KHakwO oNagc4UIj+YXA== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OKI00DLX32CFE40@st13p35im-asmtp001.me.com>; Sat, 28 Jan 2017 17:25:26 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-01-28_13:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1701280179 From: Toomas Soome Message-id: MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat Date: Sat, 28 Jan 2017 19:25:23 +0200 In-reply-to: Cc: Julian Elischer , Ngie Cooper , Allan Jude , FreeBSD Current To: Warner Losh References: X-Mailer: Apple Mail (2.3259) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2017 17:25:28 -0000 > On 28. jaan 2017, at 18:56, Warner Losh 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=