Re: GPT BIOS boot

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 30 May 2019 08:45:42 -0400
    From:        Greg Troxel <gdt%lexort.com@localhost>
    Message-ID:  <smuo93k2jrd.fsf%linuxpal.mit.edu@localhost>

  | For physical disks with 4K sectors, I agree with kre about 64, but I am
  | not sure that SSDs care about aligngment.   Today, most SSDs are small
  | enough for disklabels to work.

It isn't the underlying hardware that I was concerned with there, but the
relationshipo between FFS blocks and raidframe slices.   If you start making
FFS blocks span 2 raid slices you'll be in for a performance mess.   Since
the smallest possible FFS blocksize is 4KB, the FFS partition cannot sanely
be at anything other than a multiple of 4KB (8 512 byte blocks) from the
start of the raidframe partition (34 blocks is not a multiple of 8).  But
most common FFS filesystems use 8KB or bigger blocks, so we normally need
a multiple of 16, or more, to remain sane.  Using 64 allows for up to 32KB FFS
blocks, which should be enough for a boot/root partition (there is unlikely
to be a good reason to use something bigger.)

  | Certainly, for manu@ to handbuild bootblocks with hardcoded values that
  | make a particular system work today is a totally reasonable thing to do.

Sure, if the filesystems exist and can't be changed, and it is just
a matter of making it boot, that's what I'd do too.

  | We could do all that, but if the boot code already has to deal with gpt
  | parsing -- and it seems to deal with disklabels -- then it seems better
  | to have it read the gpt and find the right partition (first ffs?).  That
  | seems more robust than sticking an offset in the boot code.

Yes.

GPT entries have an "attributes" field which is just a bit-array.  FreeBSD
already have a "bootme" bit defined for their filesystems, we can easily
do the same to mark which GPT filesystem is to be booted (we could have
another to note which one should become root - which does not need to be
the same one, though it often will be).   There are plenty of bits...

  | Another question is why you have a gpt inside the RAID1, rather than
  | just a filesystem,

Certainly making the FFS offset from the raidframe start 0 solves
all possible alignment issues - all that matters after that is
not making the raid slices smaller than blocks.

  | but presumably that's because you want a bunch of filesystems.

Don't know about manu, but I do that all the time.

  | Another approach is to have two RAID1 sets, where the
  | first is small enough for a disklabel, and have / swap /var /usr there,

I do that too (except not usually including swap) - but these days I
still use GPT rather than disklabel, even when a disklabel would easily
cover the underlying device - just to avoing needing multiple different
partitioning methods and the need to try and remember which is used where
(aside from which, GPT labels make life so much simpler).

kre