Re: GPT BIOS boot

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

    Date:        Thu, 30 May 2019 19:36:31 +0200
    From:        manu%netbsd.org@localhost (Emmanuel Dreyfus)
    Message-ID:  <1o8emao.uzu8w71n1vuulM%manu%netbsd.org@localhost>

  | Is it documented anywhere? It would be nice if there could be a warning
  | when one choose a scenario that leads to weak performance.

Documented, I am not sure - but this kind of thing appears in
discussions on the lists from time to time.   Look for almost
any thread relating to raidframe and performance...

There is a bunch of text in raidctl(8) concerning performance,
but it looks like it ignores the file system offset aspect of
the calculations (or simply assumes that is obvious) and instead
concentrates on block vs stripe sizes (which make no sense to
compare unless the blocks are nicely aligned with the stripes).

It certainly would not hurt to add, but I'm not sure it would
necessarily help a huge amount either.  That is, I know that
at least I simply skip to the examples section of raidctl(8) and
copy them - the man page is kind of long and daunting!

Even worse, there are 4 separate steps involved in all of this,
first is setting up the partition that will contain the raidframe.
That wants to align with the underlying device blocks (and if
you've ever done a raidframe in a raidframe - which I have once
or twice, it starts getting messy, similarly for raidframe inside
CGD and similar).   Then there's the raidframe config, which wants
to have stripe sizes set to be compatible with the filesystems that
are to be used in it (which in some cases might not be known for years -
I have partitioned raidframes with empty space at the end just awaiting
a need to develop..., and they've been like that 4 or 5 years now,
every now and then I need a new XEN client, which just gets a new partition
or two made for it).

Next is the label/partitioning of the raidframe device, which
wants to take account of the stripe sizes - ideally you want the
partitions nicely aligned with stripes.   And last, there's the
filesystem parameters to config.   By the time we get to these
last two, looking back at raidframe doc isn't likely to be the
first thing we would think to do.

A warning is harder to arrange - GPT doesn't actually know it is
inside a raid (nor do disklabels or MBRs), and the filesystem in
the GPT (or whichever) partition knows even less.   I think about
the best that can be done now (unless we invent some new disk
related ioctl to obtain this info) is to simply make the defaults
be more rational (no more 63 nonsense).    sysinst does that for
you I believe (though I have never managed to get its GPT partitioning
method to work - haven't tried recently - so I'm not sure what it
does there.)

kre