From owner-freebsd-geom@FreeBSD.ORG Wed Dec 1 09:30:46 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E07971065696 for ; Wed, 1 Dec 2010 09:30:46 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id BBD938FC1F for ; Wed, 1 Dec 2010 09:30:46 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id oB19UjTx011659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Dec 2010 01:30:45 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id oB19UjZl011658; Wed, 1 Dec 2010 01:30:45 -0800 (PST) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA15162; Wed, 1 Dec 10 01:25:56 PST Date: Wed, 01 Dec 2010 01:25:33 -0800 From: perryh@pluto.rain.com To: bu7cher@yandex.ru Message-Id: <4cf6148d./XPrjnaBP5xeKIEf%perryh@pluto.rain.com> References: <4cf21cd3.UbQ57eYkszW60Ww4%perryh@pluto.rain.com> <4CF34297.4070300@yandex.ru> <4cf35138.VleaJCYj4z5kd9WX%perryh@pluto.rain.com> <4CF35809.6050704@yandex.ru> <4cf367ff.58BO71PlaI7w0e4r%perryh@pluto.rain.com> <4cf4d374.ej1zPKXBMjtfSPzw%perryh@pluto.rain.com> <4CF4EDC2.4030907@yandex.ru> In-Reply-To: <4CF4EDC2.4030907@yandex.ru> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: xcllnt@mac.com, freebsd-geom@freebsd.org Subject: Re: G_PART macro definitions X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 09:30:47 -0000 "Andrey V. Elsukov" wrote: > On 30.11.2010 13:35, perryh@pluto.rain.com wrote: > > 4 ad0s2a is offered for tasting. Gpart.bsd doesn't like it because > > it appears to contain a nested BSD label**. Gmirror finds its > > metadata at the end of ad0s2a and instantiates gm0. > > BSD label is located at the beginning of the disk, so when ad0s2a > is tasted it does detect your current (you call it as "outer") BSD > label again. There's _something_ -- probably several things -- about all this that I am not understanding at all, the most important being: How _should_ I be setting this up, so as to * mirror only one partition -- not the whole disk or the whole FreeBSD slice, * subdivide that mirror into journalled root, /var, and /usr filesystems, and * have the resulting root partition be bootable given that the system is too old for its BIOS to recognize GPT? Some of the rest, in no particular order: How is the tasting of ad0s2a managing to see the "outer" label -- the one that defines ad0s2a -- when that label is on ad0s2 prior to the first block of ad0s2a? Is tasting permitted to examine parts of the device outside the boundaries of the provider that is being tasted? If the problem arises from re-detecting the label (on ad0s2) that defines ad0s2a, while tasting ad0s2a, how does it work in the normal case where there is no second label (within ad0s2a)? Wouldn't the "outer" (now presumed only) label be redetected in that case also? If the second label is not being found during the tasting of ad0s2a, when _is_ it being found? It certainly seems to be being found at _some_ point, since we end up with ad0s2a, ad0s2d, and ad0s2e -- the letters corresponding to the second/inner label -- rather than the ad0s2a and ad0s2b which should be instantiated if only the first/outer label were being processed; furthermore the ad0s2a, ad0s2d, and ad0s2e that get instantiated seem to consist of the block ranges defined by the inner label (else gjournal would not find its metadata, and the system would not boot and run correctly once ad0s2a.journal is specified as the root FS and ad0s2[de].journal are manually mounted as /var and /usr). Why is ad0s2b never instantiated (even transiently -- I tried setting kern.geom.debugflags to 1 at the loader prompt, and ad0s2b was never mentioned at all)?