From owner-freebsd-current@FreeBSD.ORG Thu Oct 6 12:25:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 951CB1065739; Thu, 6 Oct 2011 12:25:39 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 0260F8FC1D; Thu, 6 Oct 2011 12:25:38 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p96BkF1S051778 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 6 Oct 2011 14:46:21 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4E8D9136.6040200@digsys.bg> Date: Thu, 06 Oct 2011 14:29:58 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110917 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ivan Voras References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 12:25:39 -0000 On 06.10.11 14:07, Ivan Voras wrote: > > Um, you do realize this is a "physical" problem with metadata location > and cannot be solved in any meaningful way? Geom_label stores its label > in the last sector of the device, and GPT stores the "secondary" / > backup table also at the end of the device. The two can NEVER work > together. The same goes for any other GEOM class which stores metadata > and GPT. The proper way for this is to have these things store their metadata in the first/last sector of the provider, not the underlying device. This means that, if you have GPT within GLABEL, for example -- you will only see the GPT label if you first see the GLABEL. I guess the present situation was created out of laziness ;)