From owner-freebsd-geom@FreeBSD.ORG Sat Dec 4 10:11:11 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 3A2B21065673 for ; Sat, 4 Dec 2010 10:11:11 +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 EED5A8FC1C for ; Sat, 4 Dec 2010 10:11:10 +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 oB4AB9qH031428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 4 Dec 2010 02:11:09 -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 oB4AB9UN031427; Sat, 4 Dec 2010 02:11:09 -0800 (PST) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA26646; Sat, 4 Dec 10 02:10:14 PST Date: Sat, 04 Dec 2010 02:09:44 -0800 From: perryh@pluto.rain.com To: bu7cher@yandex.ru Message-Id: <4cfa1368.rP/ZQXzGd2Jn5kHp%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> <4cf6148d./XPrjnaBP5xeKIEf%perryh@pluto.rain.com> <4CF62851.2080502@yandex.ru> <4cf77e11.P9UAmLzg7xenh4WP%perryh@pluto.rain.com> In-Reply-To: <4cf77e11.P9UAmLzg7xenh4WP%perryh@pluto.rain.com> 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: Sat, 04 Dec 2010 10:11:11 -0000 I wrote: > > 4. ad0s2a is offered for tasting. It depends which ranges has > > this provider, by default it starts with zero offset > > I had gotten the impression somewhere that "a" partitions started > at a non-zero block offset in the slice ... I found out where I got that impression: it was from observing the output of bsdlabel(8) on 8.1-RELEASE! The offset of the "a" partition is shown as 16 blocks, not zero, immediately after creating a default label with "disklabel -w". (This example is from a script(1) of the session in which I first labelled gm0; I am fairly sure that, when I was partitioning ad0s2, a: was at offset 16 also although I don't have a log of that session.) Fixit# disklabel -w -B /dev/mirror/gm0 Fixit# disklabel /dev/mirror/gm0 # /dev/mirror/gm0: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 619907501 16 unused 0 0 c: 619907517 0 unused 0 0 # "raw" part, don't edit Another example, this one from 8.0, showing that it is not "just me" who sees an "a" partition at a 16-block offset: http://lists.freebsd.org/pipermail/freebsd-questions/2010-November/224625.html Now I am back to wondering what happened to my "outer" label, originally written on ad0s2 and defining partitions ad0s2a and ad0s2b, since gm0 (and hence its label) should have started at the beginning of ad0s2a -- 16 blocks _beyond_ the start of ad0s2. Does gmirror insist on its providers being track- or cylinder- aligned?