From owner-svn-src-all@freebsd.org Wed Mar 29 22:14:32 2017 Return-Path: Delivered-To: svn-src-all@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 D3E62D24B20; Wed, 29 Mar 2017 22:14:32 +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 A9DE2A11; Wed, 29 Mar 2017 22:14:32 +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 <0ONL00L00K533M00@st13p35im-asmtp001.me.com>; Wed, 29 Mar 2017 22:14:11 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1490825651; bh=XoYj0W5a7xJTA/g4mEsH+Uf5RUNBBc7mP+vKoVJTvaU=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=g8j1EGTHzkEQDhsKiK8AL98FJu3hGTLzXaE1Vj8F4RtkOHpZSao3qE8UPnYP+Jtyg EeS2DOIM/g2oTHVV8YMsbkGMEMlr3QL4dpnAYDlH25TU8oyEcECB2iPvukgXMsikQ9 hKzeQc9wJUA21BxQ+1xivZZ16G+6jF74p3s/17aC+E1oanDFG5cO3wa4ofpggjdUC7 jWpiaqiIgW+Iq+phwLNuPzS0QNF4OfnGL8GI/yeX+kz8b53LHoJBFKLms/+PHrn/bS cztUM7l2RWWfQSKW+g3t8eI5fZwLjzHq4mbKyJHhDWqYNYYnW9xIeVkeOi4V4hKsD9 VEVjMvZOPBBgQ== 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 <0ONL00CNEKFJRM20@st13p35im-asmtp001.me.com>; Wed, 29 Mar 2017 22:14:10 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-29_17:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=8 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1703290186 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r316132 - head/sys/boot/i386/boot2 From: Toomas Soome In-reply-to: Date: Thu, 30 Mar 2017 01:14:06 +0300 Cc: Poul-Henning Kamp , John Baldwin , Ngie Cooper , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-transfer-encoding: quoted-printable Message-id: References: <201703290930.v2T9U3x9087583@repo.freebsd.org> <7448826.asYms2TLO2@ralph.baldwin.cx> <46812.1490823365@critter.freebsd.dk> To: Warner Losh X-Mailer: Apple Mail (2.3273) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 22:14:32 -0000 > On 30. m=C3=A4rts 2017, at 0:55, Warner Losh wrote: >=20 > On Wed, Mar 29, 2017 at 3:36 PM, Poul-Henning Kamp = wrote: >> -------- >> In message <7448826.asYms2TLO2@ralph.baldwin.cx>, John Baldwin = writes: >>> On Wednesday, March 29, 2017 09:30:03 AM Ngie Cooper wrote: >>=20 >>>> Log: >>>> Parameterize out 7680 (15 * 512) as BOOT2SIZE, similar to = sys/boot/i386/zfsboot/... >>>>=20 >>>> This is being done to make it easier to change in the future--this = action might be >>>> needed sooner rather than later because of gcc 6.3.0 bailing, = stating that there >>>> is negative free space left (deficit) in the boot2 bootloader. >>>>=20 >>>> MFC after: 2 months >>>> Sponsored by: Dell EMC Isilon >>>=20 >>> This can't be changed. It's baked into the BSD disklabel format. >>=20 >> No it is not, it is baked into FFS, and for UFS2 0, 8, 64 and 256K = works. >=20 > Technically, this is correct. Practically, I'm not sure we can ever > really change it. There are too many tools, scripts, etc that just > know it's 8k, even though most UFS2 systems start 64k into the volume. > UFS1 systems are still around, and there the limit is a hard limit. > And if we grow it, we run the risk of corrupting data beyond the 8k > area we've traditionally used for this. >=20 > So the constants are easy enough to change and it seems like it might > be OK. However, doing it in a safe, anti-foot-shooting way will be the > real elbow grease should someone seriously contemplate the change, > especially since the foot-shooting involved has the potential for > filesystem corruption... >=20 > But gcc 6.3 likely just needs a little TLC experimenting with its > different code generation flags... >=20 > Warner >=20 One thing is - for now we know the boot2 has not changed and we do not = really expect it to change in large scale anyhow. Second thing, yes the build process needs to be tested etc, and if = needed we can issue statement which compiler we support or not. And finally - if the space limit is really-really on the way and no = other way, then the alternate is to use freebsd-boot partition - nothing = new about it. rgds, toomas