Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Nov 2010 14:28:09 -0600
From:      CyberLeo Kitsana <cyberleo@cyberleo.net>
To:        perryh@pluto.rain.com
Cc:        freebsd-questions@freebsd.org, kraduk@gmail.com
Subject:   Re: a gmirror disappears after adding gjournals to its partitions
Message-ID:  <4CEC23D9.6090600@cyberleo.net>
In-Reply-To: <4ceb40c8.IB5c12O9ZJa3abeh%perryh@pluto.rain.com>
References:  <4ce8b7ce.qnD6CCAK8thDasFl%perryh@pluto.rain.com>	<AANLkTimb8qHPj9HTY_jpy_vzVnB27stKxXO%2BjZjhnnSd@mail.gmail.com> <4ceb40c8.IB5c12O9ZJa3abeh%perryh@pluto.rain.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 11/22/2010 10:19 PM, perryh@pluto.rain.com wrote:
> krad <kraduk@gmail.com> wrote:
>> On 21 November 2010 06:10, <perryh@pluto.rain.com> wrote:
> ...
>>> ==== manually-created config files, while still in chroot after install
>>> Fixit# cat /boot/loader.conf
>>> geom_mirror_load="YES"
>>> geom_journal_load="YES"
>>>
>>> vfs.root.mountfrom="ufs:/dev/mirror/gm0a.journal"
>>> vfs.root.mountfrom.options="rw"
> ...
>>> ==== output from kldstat, after booting the newly-installed system --
>>> ==== and manually mounting the root FS -- showing that geom_mirror.ko
>>> ==== did get loaded.
>>> Id Refs Address    Size     Name
>>>  1    6 0xc0400000 bb5504   kernel
>>>  2    1 0xc0fb6000 14540    geom_journal.ko
>>>  3    1 0xc0fcb000 16ed4    geom_mirror.ko
> ...
>> sounds silly but are you loading the gmirror kernel module via
>> loader.conf
> 
> Yes, I'm even setting geom_mirror_load to "YES" before setting
> geom_journal_load to "YES" (although I doubt the order of these
> settings in loader.conf makes any difference).
> 
> If the kldstat Id numbers are assigned sequentially, it looks as
> if geom_journal got loaded first and this may somehow be related
> (although I don't entirely see how -- absent geom_mirror to make gm0
> and its partitions visible, I'd think that geom_journal "should not"
> be able to find its metadata at all).

>From what I've found, this is because there is no taste difference
between a bsdlabel on a gmirror and a bsdlabel on a non-mirror.

Since both gmirror and gjournal are greedy (they take exclusive access
of their parent providers upon successful taste, and not upon exclusive
access to their own providers like glabel), the first one to
successfully taste and start is the winner; the other will never get to
taste those devices.

The trick here is to either make the two look different somehow (use a
different geom that stores its metadata at the beginning of the
provider, instead of the end, thus eliminating ambiguity in the bsdlabel
taste), or to make the inner geom avoid the outer devices (hardcode
provider names in metadata). Since you have an outer geom that provides
a static name, hardcoding the name of the gmirror into the gjournal
metadata shouldn't cause anything to break if your disks change places,
either.

http://pb.cyberleo.net/?show=m7fcbcef7

-- 
Fuzzy love,
-CyberLeo
Technical Administrator
CyberLeo.Net Webhosting
http://www.CyberLeo.Net
<CyberLeo@CyberLeo.Net>

Furry Peace! - http://wwww.fur.com/peace/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CEC23D9.6090600>