New BSD Installer

Hiroki Sato hrs at
Fri Feb 17 04:23:32 UTC 2012

Jeremy Chadwick <freebsd at> wrote
  in <20120217030806.GA62601 at 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> 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> >>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> 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

 # mdconfig -a -t vnode -s100m
 # mdconfig -a -t vnode -s100m
 # 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

 The size of GPT header + partition entries is 33 sectors.  So,

 # echo "(34 + 204732) * 512 + 33 * 512" | bc

 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url :

More information about the freebsd-stable mailing list