Date: Fri, 17 Feb 2012 13:20:21 +0900 (JST) From: Hiroki Sato <hrs@FreeBSD.org> To: freebsd@jdc.parodius.com Cc: wblock@wonkity.com, freebsd-stable@FreeBSD.org, mandrews@bit0.com, 000.fbsd@quip.cz Subject: Re: New BSD Installer Message-ID: <20120217.132021.880997830536801810.hrs@allbsd.org> In-Reply-To: <20120217030806.GA62601@icarus.home.lan> References: <20120217021019.GA61420@icarus.home.lan> <alpine.BSF.2.00.1202161915520.48218@wonkity.com> <20120217030806.GA62601@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Fri_Feb_17_13_20_21_2012_576)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Jeremy Chadwick <freebsd@jdc.parodius.com> wrote
in <20120217030806.GA62601@icarus.home.lan>:
fr> On Thu, Feb 16, 2012 at 07:40:35PM -0700, Warren Block wrote:
fr> > Sorry, I may be misunderstanding your point. GEOM classes don't
fr> > lie, they accurately represent the space. The space provided by a
fr> > gmirror is one block less than the actual space occupied, to allow
fr> > for the metadata block at the end. The problem is that GPT puts
fr> > backup partition tables at the end of the physical (not logical)
fr> > device. Create a GEOM device on that drive, and the GEOM metadata
fr> > overwrites the backup GPT partition table. Well, the last block of
fr> > it, anyway.
fr> >
fr> > But create the GEOM device inside a GPT partition that spans the
fr> > drive, and things are fine. The GPT backup tables are safely
fr> > outside the GEOM metadata, which is safely outside of the data.
fr>
fr> I wasn't aware you could do that. I was only aware that it was the
fr> other way around. That (my) misconception seems to also be relayed
fr> by others such as Miroslav who said:
fr>
fr> >>GPT doesn't play nice with GEOM classes which store their metadata
fr> >>on last sector. For example, you can't use gmirror of a whole drives
fr> >>and use GPT on top of this mirror. (and gmirror is not the only one)
fr>
fr> So if I read this correctly, it means that the erroneous behaviour is
fr> the result of someone doing things "in the wrong order" (for lack of
fr> better terminology).
Well, does GPT really depend on the absolute last block? The header
has fields for both the first and the last LBAs and they do not have
to be matched with the physical capacity. Creating a gmirror first,
and then creating a GPT on it does not work? I do not think it is
true, and I suspect a description on gmirror recommending
kern.geom.debugflags=17 in the handbook is the source of the problem.
The partition layout in my mind is the following:
(0) (last)
|PMBR|GPT primary| .... |GPT secondary|gmirror meta|
|<------------------------------------------------->| ada0
|<------------------------------------>| | mirror/gm0
| |<----->| | mirror/gm0p{1,2,...}
and the following commands will create an example of this
configuration:
# mdconfig -a -t vnode -s100m
md0
# mdconfig -a -t vnode -s100m
md1
# gmirror label gm0 /dev/md0 /dev/md1
# gmirror dump /dev/md0 | grep size
mediasize: 104857088
sectorsize: 512
provsize: 104857600
# gpart create -s gpt mirror/gm0
# gpart add -t freebsd-ufs mirror/gm0
mirror/gm0p1 added
=> 34 204732 mirror/gm0 GPT (100M)
34 204732 1 freebsd-ufs (100M)
# echo "(34 + 204732) * 512" | bc
104840192
The size of GPT header + partition entries is 33 sectors. So,
# echo "(34 + 204732) * 512 + 33 * 512" | bc
104857088
is the size which the GPT recognizes. This matches the size of
mirror/gm0, not /dev/md0. This means the gmirror metadata is located
just after it. I think this should work in most cases for mirroring
the whole disk.
Certainly the gpart reports "[CORRUPT]" if the underlying device
capacity does not match with the GPT header. For example,
deactivating mirror/gm0 above will show the following:
# gpart show
=> 34 204732 mirror/gm0 GPT (100M)
34 204732 1 freebsd-ufs (100M)
# gmirror stop gm0
# gpart show
=> 34 204732 md1 GPT (100M) [CORRUPT]
34 204732 1 freebsd-ufs (100M)
=> 34 204732 md0 GPT (100M) [CORRUPT]
34 204732 1 freebsd-ufs (100M)
# gpart recover md0
md0 recovered
# gpart show
=> 34 204732 md1 GPT (100M) [CORRUPT]
34 204732 1 freebsd-ufs (100M)
=> 34 204733 md0 GPT (100M)
34 204732 1 freebsd-ufs (100M)
204766 1 - free - (512B)
We can see the gpart recover extends the size to the last sector
where gmirror metadata was placed and clears the "[CORRUPT]" status
as expected.
So, some early boot stages which do not recognize mirror/gm0 see the
corrupted GPT. However, I think they will simply follow the
information in the GPT header.
-- Hiroki
----Security_Multipart(Fri_Feb_17_13_20_21_2012_576)--
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)
iEYEABECAAYFAk891YUACgkQTyzT2CeTzy2TWgCfSaDckdcDPNR/+R0nJWA1Eu5r
gtoAoNOw0gLhPM/eFwOCiABY7v88ZvmH
=TDXP
-----END PGP SIGNATURE-----
----Security_Multipart(Fri_Feb_17_13_20_21_2012_576)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120217.132021.880997830536801810.hrs>