From owner-freebsd-geom@FreeBSD.ORG Thu Oct 6 12:59:24 2011 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 1B75C1065670; Thu, 6 Oct 2011 12:59:24 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id C98498FC12; Thu, 6 Oct 2011 12:59:23 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 894A628423; Thu, 6 Oct 2011 14:59:21 +0200 (CEST) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 5340328429; Thu, 6 Oct 2011 14:59:20 +0200 (CEST) Message-ID: <4E8DA627.60003@quip.cz> Date: Thu, 06 Oct 2011 14:59:19 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 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-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: Thu, 06 Oct 2011 12:59:24 -0000 Ivan Voras wrote: >> The point was that glabel on disk device is successful, gpartitioning on >> > glabeled device is successful, but metadata handling / device tasting is >> > wrong after reboot and this should be fixed, not worked around. >> > >> > Otherwise thank you for example with GPT labels, it can be useful in >> > some cases. > 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 only way to get this sorted out is to make a label class (or adapt > glabel) which does NOT store metadata anywhere on the devices. Maybe > they can store it in the file system (a file in /etc - though you then > lose bootability, and have to somehow connect devices and labels), or > the device hardware ID can be used as a label (but not all devices have > it, and in case of "software" constructs like iSCSI the labels can be > changed). Then there should be warning in documentation or error message printed by command in the time of writing metadata. I am not a GEOM expert, but isn't it wrong concept, that glabel writes its metadata and publish original device size? If some GEOM write metadata at last sector (or first), then it should shrink the published size (or offset). Or is the problem at geom_part, that it is writing metadata past the advertised end of the device? e.g. If I have disk device with size of 100 sectors and glabel metadata is stored at the last sector, then glabel should shrink the advertised size to 99 sectors - then GPT secondary table will be at sector 99 instead of 100. I know there is problem if somebody access the device by its normal device node (e.g. /dev/ada0), then secondary GPT table will be at different place, not in last sector. But this is the mistake in glabel concept and if it cannot be solved by any other way, then glabel should not be allowed to place labels on the disk device at all. (if we cannot be sure it is non conflicting) The current state is simply wrong, because user can do something what cannot work and is not documented anywhere. Miroslav Lachman