From owner-svn-src-head@freebsd.org Wed Mar 29 21:55:50 2017 Return-Path: Delivered-To: svn-src-head@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 5771ED24469 for ; Wed, 29 Mar 2017 21:55:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 163CA7D4 for ; Wed, 29 Mar 2017 21:55:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22c.google.com with SMTP id e75so102247419itd.1 for ; Wed, 29 Mar 2017 14:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=5KhmQ6OQ86+YMJZOg+r5DUy4A7nKsF+HlZX4dH/z13Q=; b=nnTGvz8ctdCwFr2OaaFbemrso3Z9yO+pPTlfuBEon1/5BJJY8Kv+yfSMv6Q6MlFK7t 09d13LYKegWYWN9LiPUmVWhf9/wONcwLII7YYTCVmeGQEtnrNYIgPolJCA9ZC/Ocu9LE Bp1r1kwVwDGFuvqLCz5WQeIwKjkL2yBPRjAse07JloHrPnmpQQ/NbfxVd5kDyVNQpZcC 6Dniumf0kpLXIgXu9yNksbK7z3sLe1g9DafEdaPz/ytgt65uBHU50zbFFF8o0wpsk6V9 MfvNhyQ03bLMIwSvW9NjRs9TDlkzgLgflGDC3kSebCOqaTLsmmpRUW5DLHzGG/kdCAI8 cVFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=5KhmQ6OQ86+YMJZOg+r5DUy4A7nKsF+HlZX4dH/z13Q=; b=edhLWvLSKTYBtP9RvkGcVs2B4VBTSmz755C1SkRibJqvr02Q6RNkSU4+xMsUWNETR2 Tl0K6Is5CjT1V3T66YZrycyMlz06J0QU3X3HXzd0PPJRDQeEr8Kl+tDjlg9Vy88TZ59Y xhpcAgkjWxTOlC6fnjNuPa/YGJMcLg38yLPln1ZpgCpKrLJC+MatvFuVSz5xICoE82+G yuzXWncsHfVBqeqXy7LxNsfIROW1CzA0glCpnqXJcn4qHywGbCYGgIGT3JtsJNM8O34t MNX5ozjN3jz6iwy40bprhsGROHo4ANv5sVeiHJWIZB/j3/S/EYWVL9ApCnuwBY/msn3X hbwg== X-Gm-Message-State: AFeK/H2vbFS8MHBxVdCpt/Ueb0EKhjILrAuRYaSOlmq5e0DDAP+rXMALzyAE1utvhtONiTBm24Z2K0cnJl/9Zw== X-Received: by 10.36.131.201 with SMTP id d192mr753425ite.60.1490824549316; Wed, 29 Mar 2017 14:55:49 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.146.24 with HTTP; Wed, 29 Mar 2017 14:55:48 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:a045:c633:4156:d07c] In-Reply-To: <46812.1490823365@critter.freebsd.dk> References: <201703290930.v2T9U3x9087583@repo.freebsd.org> <7448826.asYms2TLO2@ralph.baldwin.cx> <46812.1490823365@critter.freebsd.dk> From: Warner Losh Date: Wed, 29 Mar 2017 15:55:48 -0600 X-Google-Sender-Auth: 6Otl0OE4bE7CC-cRdzqyeboBoIU Message-ID: Subject: Re: svn commit: r316132 - head/sys/boot/i386/boot2 To: Poul-Henning Kamp Cc: John Baldwin , Ngie Cooper , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 21:55:50 -0000 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: > >>> Log: >>> Parameterize out 7680 (15 * 512) as BOOT2SIZE, similar to sys/boot/i386/zfsboot/... >>> >>> 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. >>> >>> MFC after: 2 months >>> Sponsored by: Dell EMC Isilon >> >>This can't be changed. It's baked into the BSD disklabel format. > > No it is not, it is baked into FFS, and for UFS2 0, 8, 64 and 256K works. 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. 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... But gcc 6.3 likely just needs a little TLC experimenting with its different code generation flags... Warner