Re: GPT BIOS boot

[Greg Troxel <gdt%lexort.com@localhost>]

manu%netbsd.org@localhost (Emmanuel Dreyfus) writes:

> Robert Elz <kre%munnari.OZ.AU@localhost> wrote:
>
>> But that's just plain insane ... if that matches your setup, you should
>> start again.  For raid it is even more important than with normal FFS
>> that the blocks be sensibly aligned, and while 34 is (marginally) better
>> than 63, that's all it is.   64 would be better (it is at least a power of
>> 2, if a small one).   
>
> It matches the most obvious setup where the RAID contains just a GPT
> followed by a FFS partition, but indeed, there is room for improvement.

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.

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

> We could have an installboot(8) option for that. Something like:
> installboot -o raid1_root_start=34 /dev/rdk1 bootxx_ffsv2
>
> installboot(8) could detect the GPT-inside-RAID1 situation, inspect the
> GPT and set the appropriate value correctly. 

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.

Another question is why you have a gpt inside the RAID1, rather than
just a filesystem, but presumably that's because you want a bunch of
filesystems.  Another approach is to have two RAID1 sets, where the
first is small enough for a disklabel, and have / swap /var /usr there,
and then have the second one be a bare fs as /huge0.  But that's a
workaround and it would be nice to improve the boot code.