Re: GPT BIOS boot

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

    Date:        Fri, 31 May 2019 03:18:34 +0200
    From:        manu%netbsd.org@localhost (Emmanuel Dreyfus)
    Message-ID:  <1o8f7tn.xdp9e7tkf06uM%manu%netbsd.org@localhost>

  | My understanding is that without a GPT inside the RAID1, you have no way
  | to get a filesystem bigger than 2 TB. 

I don't think that's correct - or at least it should not be (though I
haven't tried it) - but a FFS into a raw (perhaps virtual) disk should be
able to be as big as the disk (minus FS overheads).   The filesystem doesn't
care where the size comes from - a filesystem in a GPT partition is the
same filesystem as one on a bare drive, or in a vnd or raidframe, or one
in an MBR or disklabel partition.

I suspect that what you're thinking of is when some other partitioning
scheme is used - both MBR and disklabel are limited to 32 bit block
counts and offsets.    (GPT isn't).    Nb: block counts: if you have a
4KB block size device, then you can get (2^32 -1 ) * 4K bytes of
filesystem size, even with those old labelling methods.  In fact, I
suspect that's the real reason that there was, for a period, a phase
where drive manufacturers sold drives that worked that way, without
512 block size emulation stuck on top of whatever the hardware actually
uses, which is what is (again) most common.

So, if your raidframe only needs to contain a single filesystem, you can
just use raidN as the device (on modern NetBSD, raidN[cd] on older versions)
and build a filesystem on that.   (The [cd] forms still work, raidN is
just a shorthand for whichever of those is the right one for the system.
The same works for anything of course, not just raid.)

kre