From owner-freebsd-current@FreeBSD.ORG Thu Oct 6 12:59:51 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 80F7B1065746 for ; Thu, 6 Oct 2011 12:59:51 +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 DE1078FC19 for ; Thu, 6 Oct 2011 12:59:50 +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 p96Cxckj052192 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 6 Oct 2011 15:59:43 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4E8DA257.9080406@digsys.bg> Date: Thu, 06 Oct 2011 15:43:03 +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: freebsd-current@freebsd.org 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> <4E8D9136.6040200@digsys.bg> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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:59:51 -0000 On 06.10.11 15:36, Ivan Voras wrote: > On 06/10/2011 13:29, Daniel Kalchev wrote: >> >> 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 ;) > No, I don't think you understand. > > The layering *is* correct and you *can* create a GPT inside a glabel > label, but then > > 1) you get device names like /dev/label/somethingp1, > /dev/label/somethingp2, etc. .. and, you overwrite the last sector of the device, not of the provider. This is incorrect layering -- GPT should see only the provider it was given and nothing at different layers. > > 2) this makes the device unbootable as the GPT partition is per > definition not valid. It still stores the primary partition table on the > first sector (and the following sectors...), but its secondary table is > stored at one sector short of device's last sector (which is used by > glabel). Any utilities and BIOSes which test for GPT will find the first > table but not the last and depending on how sensitive / broken they are, > they will either recognize a broken GPT (and/or try to fix it, > destroying the glabel label), or not work at all. This is why I said, "lazy". If you use proper layering, the GPT within another GEOM provider should be unbootable. No BIOS should ever "see" it. The rationale of using GPT within another GEOM is questionable, but apparently has applications. > You could argue that the GPT design is broken, but it was always, per > design, only made to work on whole drives. There is no way to use it > with any other scheme which uses either the first or the last sectors of > a drive. I am not arguing this. But suppose you use GPT on HAST providers. These cannot boot so whether GPT is bootable in that case is irelevant. > Luckily, GPT also provides its own labels (per design) and instead of > labeling the provider, you could just as easily label the individual > partitions and skip glabel in this case. > That is another option, yes. But this does not mean we do not have a issue. Probably, it should be simply disallowed to use GPT within GLABEL. Or, in cases where this might be beneficial, use sort of 'boot-less' GPT. Probably, the problem here is with GLABEL, that does not use the first sector as well.