From owner-svn-src-head@freebsd.org Tue Mar 28 16:07:25 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 DD4A4D226A5; Tue, 28 Mar 2017 16:07:25 +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 B440C20B; Tue, 28 Mar 2017 16:07:25 +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 <0ONJ00N008ER2Y00@st13p35im-asmtp001.me.com>; Tue, 28 Mar 2017 16:07:17 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1490717236; bh=8AasVPW+rVdImHldV070NxGirRdnw2/St7KLq3hhmP8=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=Ny8NASJt0DJTEucQl4NpmgULwI/vMbm3Z19FxHDkHktEhOhmUDlWJkfWmjt+ErXG3 zL04BRSCGleIbkwOxIoH0dv8cq9pcQyZNmpRaRN+0/8YhaowRrUexTH4Puy8NAXoIE G6+Rf6JczrzyMkqbdckXjjmVVAKXloDf8eMnizo8nXhHY5i6h9Ph7tDR32AKsIubVh on8fDfUwuIYwz2fZKvtQiAneof0asplIMtutvT3uTOokyimQFsEOP5OxGDmZf1dOy8 rPGokt4kqOVMy/gSVp5LeaIOVrd1VW4wIsCAKhk67Eg7s8QTLW/dFa21+9v1fFNE91 5+5J4I7a7J1LQ== 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 <0ONJ00MG28S1UW00@st13p35im-asmtp001.me.com>; Tue, 28 Mar 2017 16:07:16 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-28_13:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1703280134 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: svn commit: r316064 - head/sys/boot/i386/boot2 From: Toomas Soome In-reply-to: <201703281555.v2SFtoSU005538@pdx.rh.CN85.dnsmgr.net> Date: Tue, 28 Mar 2017 19:07:13 +0300 Cc: Bruce Evans , Julian Elischer , Warner Losh , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-transfer-encoding: quoted-printable Message-id: <8EB5A473-1218-4A57-8741-374669A9F5B8@me.com> References: <201703281555.v2SFtoSU005538@pdx.rh.CN85.dnsmgr.net> To: rgrimes@freebsd.org X-Mailer: Apple Mail (2.3259) 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 16:07:26 -0000 > On 28. m=C3=A4rts 2017, at 18:55, Rodney W. Grimes = wrote: >=20 >> On Mon, 27 Mar 2017, Julian Elischer wrote: >>=20 >>> On Tue, 28 Mar 2017, Bruce Evans wrote: >>>=20 >>> [...] >>>=20 >>>> 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 >>>=20 >>> My memory says that the limit of 7.5K is becuase there was only 8k = left free=20 >>> at the front of UFS1 and one sector was used for the boot0 code. >>=20 >> 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 >> 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. >>=20 >> Bruce >=20 > --=20 > Rod Grimes = rgrimes@freebsd.org >=20 Also note that SunOS (which ufs is based on ufs1), has disk layout on = sparc as sector 0 for VTOC (512B), followed by 15 sectors for bootblk, = total 16 sectors, or 8KB, the setup which did allow to define slice 0 to = start from the absolute sector 0, and which probably did also burn = uncounted amount of DBA=E2=80=99s who did attempt the same for their raw = databases;) rgds, toomas=