Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Feb 2012 21:37:48 -0800
From:      Freddie Cash <fjwcash@gmail.com>
To:        Warren Block <wblock@wonkity.com>
Cc:        Mike Andrews <mandrews@bit0.com>, freebsd-stable@freebsd.org, Miroslav Lachman <000.fbsd@quip.cz>, Jeremy Chadwick <freebsd@jdc.parodius.com>
Subject:   Re: New BSD Installer
Message-ID:  <CAOjFWZ40d2g0URj=ZTD62gPyXtQZgc07h8v02PCqk1sm3%2Bqo9A@mail.gmail.com>
In-Reply-To: <alpine.BSF.2.00.1202161915520.48218@wonkity.com>
References:  <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> <20120213195554.O46120@sola.nimnet.asn.au> <092c01cceb40$2dc8f240$895ad6c0$@fisglobal.com> <CAN6yY1uVhXMntWaK=P4dPrKY3aLR2fsKMWfS7Ncvpwy-XKM31Q@mail.gmail.com> <095a01cceb54$04a38fb0$0deaaf10$@fisglobal.com> <4F3ACDE7.8060003@bit0.com> <4F3D9A7C.7080900@quip.cz> <20120217001829.GA59869@icarus.home.lan> <alpine.BSF.2.00.1202161817500.47990@wonkity.com> <20120217021019.GA61420@icarus.home.lan> <alpine.BSF.2.00.1202161915520.48218@wonkity.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 16, 2012 at 6:40 PM, Warren Block <wblock@wonkity.com> wrote:
> On Thu, 16 Feb 2012, Jeremy Chadwick wrote:
>
>> On Thu, Feb 16, 2012 at 06:34:53PM -0700, Warren Block wrote:
>
>
> (...Linux mdadm)
>
>> So for version 0.90 of their metadata format, you lose drive capacity by
>> about 64-128KBytes, given that the space is needed for metadata. =C2=A0F=
or
>> version 1.0, I'm not sure. =C2=A0For version 1.1 it looks like the metad=
ata
>> can be stored at the beginning.
>>
>> So overall, this sounds to me like the equivalent of if GEOM was to
>> "lie" about the actual capacities of the devices when using classes that
>> require use of metadata (gmirror, etc.).
>
> Sorry, I may be misunderstanding your point. =C2=A0GEOM classes don't lie=
, they
> accurately represent the space. =C2=A0The space provided by a gmirror is =
one
> block less than the actual space occupied, to allow for the metadata bloc=
k
> at the end. =C2=A0The problem is that GPT puts backup partition tables at=
 the end
> of the physical (not logical) device. Create a GEOM device on that drive,
> and the GEOM metadata overwrites the backup GPT partition table. =C2=A0We=
ll, the
> last block of it, anyway.
>
> But create the GEOM device inside a GPT partition that spans the drive, a=
nd
> things are fine. =C2=A0The GPT backup tables are safely outside the GEOM
> metadata, which is safely outside of the data.
>
> Short-form: GPT tables are at the absolute start and end of the physical
> disk. =C2=A0GEOM metadata is relative, at the end of the logical device, =
not
> necessarily the end of the physical device.

Seems to me that we need a GEOM-aware loader that can "taste" the GEOM
metadata on a disk *before* the GPT is read, such that the "first and
last physical block of the disk" becomes "the first and last physical
block of the GEOM provider".  Perhaps by storing the GEOM class
metadata in the first and last blocks of the provider.  Then you just
start reading the start of the disk, notice a gmirror metadata block,
setup the gmirror, notice a gstripe metadata block, setup the gstripe,
notice a GPT metadata block, load the GPT partitions, etc

No idea just how feasible this would be, though.

--=20
Freddie Cash
fjwcash@gmail.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOjFWZ40d2g0URj=ZTD62gPyXtQZgc07h8v02PCqk1sm3%2Bqo9A>