From owner-freebsd-geom@FreeBSD.ORG Mon Nov 10 11:41:27 2008 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 177081065686 for ; Mon, 10 Nov 2008 11:41:27 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8B8F58FC2E for ; Mon, 10 Nov 2008 11:41:26 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KzV91-0002RG-Pu for freebsd-geom@freebsd.org; Mon, 10 Nov 2008 11:41:23 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 10 Nov 2008 11:41:23 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 10 Nov 2008 11:41:23 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Vadim Goncharov Date: Mon, 10 Nov 2008 11:41:15 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 46 Message-ID: References: <48FF2607.10807@icyb.net.ua> <63F8346D-0116-4F41-BCAA-C235E9657BD8@mac.com> <48FF82BA.3020309@icyb.net.ua> <48FF913A.9070700@icyb.net.ua> <7334715F-FAE1-40EE-92EB-468041587410@mac.com> <0244407E-F10C-4374-9D68-557C1DA31EB3@mac.com> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Marcel Moolenaar User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: gpart oddity X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2008 11:41:27 -0000 Hi Marcel Moolenaar! On Wed, 05 Nov 2008 09:28:19 -0800; Marcel Moolenaar wrote about 'Re: gpart oddity': >> The question is, how much strict it is? Currently I have an 6.2-S >> system with >> gmirror(8)'ed slices, not disks, as it was converted from existing >> system >> with different sizes of disks. I have had edit their labels that >> partition >> 'c' doesn't cover entire unit (and last partition was reformatted to >> be not >> truncated, too). This is needed to be sure that last sector gets not >> overwritten by gmirror(8) metadata, but bsdlabel(8) always complains >> about it >> that it doesn't cover bla-bla-bla. Moreover, labeled partitions and >> slices >> exist on their own, despite of gmirror(8). And yet more, if I try to >> do a >> bsdlabel(8) on a gm0, it will complain about 63 sectors boot offset, >> while >> on ad0s1 it will not, so I need to hack a lot if I need to resize >> partitions. >> >> What is the cause of the trouble? > From what you tell, I think the problem is caused by > forcing the proverbial square peg into the proverbial > round hole. > We made it too easy for people to create invalid labels > because we simply didn't do any real sanity checking > and/or didn't provide any real tools to help the user > achieve what they want. > The fact that gmirror puts the metadata in the last > sector and only adjusts the media size of the provider > when in use, means that we have introduced ambiguity > in how the GEOMs are stacked and while the gmirror > approach is a feature on the one hand, we have done so > without regard for the validity of disklabels. We > handwaved the problems as unimportant or aesthetic. But the question is, what I will have to do with my setup? Will it still work in future versions? -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]