From owner-svn-src-all@freebsd.org Wed Mar 29 21:55:50 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 57269D24468 for ; Wed, 29 Mar 2017 21:55:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 10FB07D3 for ; Wed, 29 Mar 2017 21:55:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22a.google.com with SMTP id 190so64822745itm.0 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=NmkCyVj0HLEZQWI9FmayVe8sP4mbUQZ1nUV7+zVJ4fGOQENe3xJfwgXFdq0wFatxe2 WFJ1XI47hig89alHIifh0IwHofSAd9GaIoo5nba+4N0RTczD0B7ARkPa9XcPfY/XlrJp Qhi1Y/5V7URndQsOHNBtt0ZVu/SUxJDGzQD18nkmjrznGNdzfkz/j8/JuuseT47mX6Bc XsnXodJrn76zna+w53HhbA/CxU1Eudz9YanVJ8jeiHvcM86U4TrXukeFXWOTworer/5D R6PWRxEGg3k07og28QsSnSvJ5GPZUO82CZVukMe+ubAu4h0LE5wMss5LQ6iLUUmoxq7y hjQg== X-Gm-Message-State: AFeK/H3mBcTEWDfHqNiI14+L/DKYDyHw33Op5O2BQ9Pnn1dEBI3LBY2Eg1bllBVlxc9R1kJkgO5QdDPwffJ2jg== 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-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 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