svn commit: r316064 - head/sys/boot/i386/boot2

[Bruce Evans]

On Tue, 28 Mar 2017, Rodney W. Grimes wrote:

>> 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.

Dangerously dedicated is still often partitioned, except on floppies.

> 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.

The #define is BBSIZE, but struct disklabel always (at least as far back
as FreeBSD-1) had a variable field d_bbsize for it.  The support for
changing the variable is just fairly broken.  struct disklabel also has
d_sbsize for giving the maximum size of the "fs" superblock.  These fields
might be limited by the fs iff the label is inside an fs partition.  They
are in practice for ffs.  Other fs's might not even have an ffs-style
superblock.

The offset is necessary for separate protection on the metadata and the
file system.  I still have to fight the geom's protection.
kern.debug/geomflags sometimes works.

If there were more partitions then the metadata should be on a separate
one.  Of course, you might want the same protection on the label and
the root partition, to make it harder to change either.

> 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.

boot1 is normally part of boot2, and only exists logically.

boot0 should have size 1 sector (or 512 bytes) since the second sector
is more likely to be clobbered by other OSes and BIOSes and you can't
control these.  Windows even scribbles a disk id on the first sector.

> 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.

Only true for ffs in the very dangerously dedicated case with no
partitions :-).  The boot blocks are somewhat constrained by this.  You
need small ones if you want to support the worse case of ffs1 on a very
dangerously dedicated disk.  Once you have written these, it is simplest
to use them in all cases.

Bruce