Date: Sat, 27 Jun 2009 13:15:46 +0200 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-geom@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: gmirror gm0 destroyed on shutdown; GPT corrupt Message-ID: <h24v15$70v$1@ger.gmane.org> In-Reply-To: <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Marcel Moolenaar wrote: > > On Jun 25, 2009, at 4:02 AM, Anton Shterenlikht wrote: >> dev_taste(DEV,mirror/gm0) >> g_part_taste(PART,mirror/gm0) >> >> GEOM: mirror/gm0: the secondary GPT table is corrupt or invalid. >> GEOM: mirror/gm0: using the primary only -- recovery suggested. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > You created the mirror after the GPT, which means you destroyed > the GPT backup header. gmirror uses the last sector on the disk > for metadata and that by itself is a cause for various problems. > > It's better to use gmirror per partition. Or create the GPT partition inside the gmirror device - then the GPT backup table will be at last_sector-1, but... > You could run into a race condition between GPT and gmirror and > GPT winning (again the result of gmirror using the last sector > on a disk for metadata). unfortunately this could still happen, and will lead to the same error if GPT is tasted first, since it is embedded in the first sector and will assume the whole drive is available to GPT, and will then proceed to not find its backup data in the last sector. It looks to me like GEOM classes should have a "priority" field for tasting. Any objections to that idea?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?h24v15$70v$1>