From owner-svn-src-head@freebsd.org Tue Mar 28 15:55:54 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 EEFA6D2229F; Tue, 28 Mar 2017 15:55:54 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B1AFBB38; Tue, 28 Mar 2017 15:55:53 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v2SFtpT2005539; Tue, 28 Mar 2017 08:55:51 -0700 (PDT) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v2SFtoSU005538; Tue, 28 Mar 2017 08:55:50 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201703281555.v2SFtoSU005538@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r316064 - head/sys/boot/i386/boot2 In-Reply-To: <20170328192226.F1710@besplex.bde.org> To: Bruce Evans Date: Tue, 28 Mar 2017 08:55:50 -0700 (PDT) CC: Julian Elischer , Warner Losh , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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: Tue, 28 Mar 2017 15:55:55 -0000 > On Mon, 27 Mar 2017, Julian Elischer wrote: > > > On Tue, 28 Mar 2017, Bruce Evans wrote: > > > > [...] > > > >> they have to fit below 640K and a few multiples of 64K are already > >> used for buffers). The limit on 8K is mainly a historical mistake. > >> A limit of 7.5K simplified booting from 15-sector floppies. 18-sector > > > > My memory says that the limit of 7.5K is becuase there was only 8k left free > > at the front of UFS1 and one sector was used for the boot0 code. > > That is only a limit if the boot code is in the ffs partition. This causes > other problems. It was the default to start the 'a' partition at offset 0, > but that was changed 10-15 years ago. I can't find exactly where it is > changed. I use an offset of 8192 sectors or 4M on new and repartitioned > hard disks. IIRC, it was sizeof(boot0)+sizeof(boot1) had to fit in the 8K byte hole at the start of a ffs/ufs1 disk if and only if the disk was in dangeriously dedicated mode, which is the same case for a floppy. This 8K hole, again iirc, is actually a #define. Later someone seems to have though you need to offset partition a: by 16 blocks for this and made the installers do magic this, as far as I can see, is incorrect and I have manually been reseting the first partition of my bsdlabels to 0 and adding 16 blocks to there size. I think we still have an 8k size limit on boot1 for ffs/(ufs1 or ufs2) (Proved self wrong on the 8k limit, see comments from sys/ufs/ffs/fs.h below) as it this code still lives in the start of the partition, though there is usually 62 (or some other similiar number that is geometry dependent) sectors of unused space between the mbr and the start of the bsd slice. Here is the truth on the magic holes from sys/ufs/ffs/fs.h: * Depending on the architecture and the media, the superblock may * reside in any one of four places. For tiny media where every block * counts, it is placed at the very front of the partition. Historically, * UFS1 placed it 8K from the front to leave room for the disk label and * a small bootstrap. For UFS2 it got moved to 64K from the front to leave * room for the disk label and a bigger bootstrap, and for really piggy * systems we check at 256K from the front if the first three fail. In * all cases the size of the superblock will be SBLOCKSIZE. All values are * given in byte-offset form, so they do not imply a sector size. The * SBLOCKSEARCH specifies the order in which the locations should be searched. > This is again affected by the existence of floppy disks. Floppy disks are > usually not partitioned, and don't have space to spare for large boot > blocks. Some version of the boot code has to work on small media, and > FreeBSD uses the same boot code for all media. This allowed FreeBSD-1 > to have a single boot.flp where IIRC Linux had about 100 variations. > Small media is not as small as it used to be. > > Bruce -- Rod Grimes rgrimes@freebsd.org